2016-07-12 23 views
0

So arbeite ich mit einer komplexen Code-Basis, mit vielen Modellen einer ERP-Lösung in Rails 4 mit RSpec und FactoryGirl getan. Glücklicherweise hat es viele Tests, nicht so viel wie es ideal wäre, aber eine vernünftige Anzahl. Einer der Punkte, an denen wir zu kämpfen hatten, war immer eine komplexe Fabrikeinstellung. Um zum Beispiel eine einfache Rechnung zu erstellen wir haben eine Menge Arbeit zu tun:FactoryGirl Standard Weg zum Erstellen komplexer Fabriken (Modell Kopplung Anliegen)

product = create(:product, business: test_business, price: 100) 
activity = create(:activity, business: test_business) 
create(:sales_point, business: test_business, fiscal_number: 1) 
user = create(:user) 
Invoice.create!(business: test_business, 
       sales_point: 1, 
       invoice_type: InvoiceType::INVOICE_B, 
       receptor_fiscal_category: FiscalCategory::BUSINESS_A, 
       details: [InvoiceDetail.new(product: product, 
              description: product.name, 
              unitary_amount: 100, 
              quantity: 1, 
              amount: 100, 
              activity: activity)], 
       total_net: 100, 
       total_tax: 21, 
       total_amount: 121, 
       created_by: user, 
       updated_by: user) 

Und das ist nur für eine einfache Rechnung für die Prüfung zu schaffen! Ich weiß, dass Thoughtbots, FactoryGirl-Entwickler, sich tatsächlich dagegen aussprechen, mehrere Fabriken für dasselbe Modell oder zu viel Komplexität auf ihnen zu haben. Und ich kann verstehen, warum .. wenn Sie beginnen zu viel Magie auf Fabriken zu tun, werden sie zu viel mit Ihren Tests gekoppelt .. und plötzlich ändern Sie etwas und bang .. Hunderte von Test Start fehlgeschlagen.

Also anstatt Dinge zu ändern oder zu "schlau" zu sein, haben wir am Ende 5-10 Versionen von Fabriken für komplexe Modelle wie Rechnung (z. B. invoice_by_total_ammount, invoice_by_product_list, invoice_cash, etc).

Die Frage ist, Wenn Sie jemals in großen Codebasen wie diesem (100 ~ Modelle) gearbeitet haben, was war der Standard Weg, um mit dieser Art von komplexen Setup umzugehen, um Objekte zu testen? Wie gut war es?

+0

Das alles scheint ziemlich normal. Der Standard-Ansatz von factory_girl wäre, eine Rechnungsfabrik zu schreiben, die automatisch die zugehörigen Objekte erstellt. Hast du das probiert? Hat es gut für dich funktioniert? Es gibt einige spezielle Tricks, die nötig sind, um factory_girl dazu zu bringen, dieselbe transitive Abhängigkeit für mehrere Assoziationen zu verwenden, aber es ist mir nicht klar, ob das das Problem ist, das Sie haben. –

+0

Ja, wir haben das gemacht ... aber verschiedene Tests erforderten verschiedene Verbesserungen am Modell, das mit Rechnungen erstellt wurde, und begannen, sehr gut mit der Fabrik verbunden zu werden. Auch wir haben mit ungefähr 5-6 verschiedenen Versionen der Rechnungsfabrik geendet. –

+0

Möglicherweise sollten Sie ein paar Versionen der Fabrik zeigen und fragen, wie man sie konsolidiert. –

Antwort

0

Ich würde empfehlen, diesen Codeblock in eine Funktion einzubinden und den gewünschten Rechnertyp als Parameter zu übergeben.

Diese Art von Funktionen können in eine Hilfsdatei eingefügt werden, und diese Datei kann in Ihrem Rspec.configure Block enthalten sein, damit sie für alle Ihre Tests verfügbar ist.

+0

Dort gibt es relevante Daten, die Test zu Test ändern sollten. Ich werde am Ende mit 8-10 Funktionen die gleichen wie mit Fabriken. Ich bin immer noch auf der Suche nach einer Antwort "War da, tu das". Entschuldigung. –

+0

Wir verwenden ähnliche Ansätze in unserer Codebasis. Leider kann der eigentliche Code nicht geteilt werden, aber die generelle Idee ist es, den "Typ" der Kampagne, die Sie erstellen möchten, und verwandte Produkte, Bestellungen und Bestellartikel zu übergeben. Verschiedene Attribute, die wir verwenden, sind Kampagnentyp, Kampagnenstatus, Bestellstatus, Anzahl der Bestellpositionen. –

+0

Sie haben also eine Art Factory Methods Ansatz auf den Fabriken bekommen. Das kann sauberer sein als komplexe Fabriken mit kniffligen Rückrufen, das stimmt. –