BDD/TDD Mocking Daten die knifflige Art und Weise

Question

So ein Kollege und ich sind in einer ziemlich hitzigen Debatte. Wir beginnen ein neues Projekt und versuchen BDD zu verwenden. Wir sind beide Neulinge und verstehen nicht ganz, welche Praktiken verwendet werden sollten. Wir haben einige Spezifikationen geschrieben und implementieren jetzt den Code. Die Dinge werden ziemlich schwierig, da es viele Datenbankinteraktionen gibt. Wir stecken fest, wie wir unsere Daten verspotten sollten. Die Methode, die wir durchführten, verlangte von uns, unsere Methoden zu verspotten anstatt unsere Daten. Es ist am einfachsten, wenn ich Sie in Code zeigen ...

public static void AssignLeadToDistributor(int leadId, int distributorId) 
{ 
    Lead lead = GetById(leadId); 
    lead.DistributorId = distributorId; 
    Save(lead); 
} 

Grundsätzlich würden wir GetById außer Kraft setzen müssen() und Save() Mock Daten zurück für uns, dies zu testen. Es scheint mehr Sinn zu machen, wie dies zu tun:

public static void AssignLeadToDistributor(Lead lead, Distributor distributor) 
{ 
    lead.DistributorId = distirbutor.Id; 
} 

Dann könnten wir nur unsere Objekte verspotten.

Die zweite Methode erleichtert eindeutig das Testen. Das Argument ist jedoch, dass wir kein neues Lead- und Verteilerobjekt in unserem Front-End-Code abrufen müssen, da es einfacher wäre, die IDs unserer Objekte einfach zu übergeben. Reduzieren Sie den tatsächlichen Code in unserem Frontend.

Hoffentlich habe ich das gut genug erklärt.

Was denkst du? Welcher Weg ist sinnvoller?

Answer 1

Was wir in unseren BDD-Spezifikationen (ausführbare Stories) tun, ist, die Datenbank überhaupt nicht zu verspotten, sondern stattdessen eine In-Memory-DB (in unserem Fall SQLite) zu verwenden.

Außerdem initialisieren wir den Container, bevor ein Szenario ausgeführt wird. Das liegt daran, dass wir möchten, dass unsere BDD-Spezifikationen die reale Welt so weit wie möglich nachahmen und trotzdem die Geschwindigkeit gewöhnlicher Komponententests haben.

Indem wir unsere BDD-Spezifikationen auf diese Weise definiert haben, haben wir festgestellt, dass Komponententests und Integrationstests weniger erforderlich sind und sowohl eine höhere Produktivität als auch eine bessere Verständlichkeit erzielen (obwohl sehr subjektiv, da diese Metriken nicht wirklich gemessen werden können).

Answer 2

Ich denke, das größte Problem, das Sie haben, ist, weil Sie öffentliche statische Funktionen verwenden (was in OO-Sprachen normalerweise eine schlechte Sache ist).

Ich würde vorschlagen, um diese Funktion zu dem Lead-Objekt bewegt, so etwas wie

public AssignDistributor(int distributorId) { 
    this.DistributorId = distributorId; 
    this.Save(); 
} 

einfacher zu testen und mehr OO-like code =)

Answer 3

Ich mag die zweite Methode besser, für die Grund, den Sie angegeben haben: Sie können die Parameter leicht zum Testen verspotten. Verwenden Sie ein Abhängigkeits-Injection-Framework? Wenn nicht, dann empfehle ich Ihnen, Ihre Methoden trotzdem mit dem Dependency Injection-Prinzip zu programmieren, um einen modulareren und einfach zu testenden Code zu erhalten.

Und ich stimme Samuel zu, dass Sie wann immer möglich statische Methoden vermeiden sollten, oder Sie werden es sehr schwierig finden, sie zu testen.