Wo liegt die Grenze zwischen Unit-Testing-Anwendungslogik und misstrauischen Sprachkonstrukten?

Betrachten Sie eine Funktion wie diese:

function savePeople(dataStore, people) {
    people.forEach(person => dataStore.savePerson(person));
}

Es könnte so verwendet werden:

myDataStore = new Store('some connection string', 'password');
myPeople = ['Joe', 'Maggie', 'John'];
savePeople(myDataStore, myPeople);

Nehmen wir an, dass dies Storeeigene Komponententests hat oder vom Hersteller bereitgestellt wird. Auf jeden Fall vertrauen wir Store. Und nehmen wir weiter an, dass die Fehlerbehandlung - z. B. von Fehlern bei der Trennung der Datenbank - nicht in der Verantwortung von liegt savePeople. Nehmen wir in der Tat an, dass der Speicher selbst eine magische Datenbank ist, die in keiner Weise fehlerfrei sein kann. Angesichts dieser Annahmen lautet die Frage:

Sollte savePeople()ein Unit-Test durchgeführt werden, oder würden solche Tests dem Testen des eingebauten forEachSprachkonstrukts gleichkommen?

Wir könnten natürlich einen Schein abgeben dataStoreund behaupten, der dataStore.savePerson()für jede Person einmal aufgerufen wird. Sie könnten durchaus das Argument vorbringen, dass ein solcher Test Sicherheit gegen Implementierungsänderungen bietet: Wenn wir uns beispielsweise dafür entscheiden, ihn durch forEacheine herkömmliche forSchleife oder eine andere Methode der Iteration zu ersetzen . Der Test ist also nicht ganz trivial. Und doch scheint es furchtbar nahe ...

Hier ist ein weiteres Beispiel, das möglicherweise fruchtbarer ist. Stellen Sie sich eine Funktion vor, die nur andere Objekte oder Funktionen koordiniert. Zum Beispiel:

function bakeCookies(dough, pan, oven) {
    panWithRawCookies = pan.add(dough);
    oven.addPan(panWithRawCookies);
    oven.bakeCookies();
    oven.removePan();
}

Wie sollte eine Funktion wie diese Unit getestet werden, vorausgesetzt, Sie glauben, dass dies der Fall ist? Es ist schwer für mich , jede Art von Gerät zu testen , sich vorzustellen , die einfach nicht spotten dough, panund oven, und dann behaupten , dass Methoden auf sie genannt werden. Ein solcher Test ist jedoch nichts anderes, als die exakte Implementierung der Funktion zu duplizieren.

Zeigt diese Unfähigkeit, die Funktion in einer aussagekräftigen Black-Box-Weise zu testen, einen Konstruktionsfehler bei der Funktion selbst an? Wenn ja, wie könnte es verbessert werden?

Um die Frage, die das bakeCookiesBeispiel motiviert , noch klarer zu gestalten, füge ich ein realistischeres Szenario hinzu, auf das ich beim Versuch gestoßen bin, dem Legacy-Code Tests hinzuzufügen und ihn umzugestalten.

Wenn ein Benutzer ein neues Konto erstellt, müssen einige Dinge geschehen: 1) Ein neuer Benutzerdatensatz muss in der Datenbank erstellt werden. 2) Eine Begrüßungs-E-Mail muss gesendet werden. 3) Die IP-Adresse des Benutzers muss für Betrugsfälle aufgezeichnet werden Zwecke.

Deshalb möchten wir eine Methode erstellen, die alle Schritte "Neuer Benutzer" miteinander verbindet:

function createNewUser(validatedUserData, emailService, dataStore) {
  userId = dataStore.insertUserRecord(validateduserData);
  emailService.sendWelcomeEmail(validatedUserData);
  dataStore.recordIpAddress(userId, validatedUserData.ip);
}

Beachten Sie, dass, wenn eine dieser Methoden einen Fehler auslöst, der Fehler in den aufrufenden Code aufsteigen soll, damit er den Fehler nach Belieben behandeln kann. Wenn es vom API-Code aufgerufen wird, übersetzt es den Fehler möglicherweise in einen entsprechenden http-Antwortcode. Wenn es von einer Webschnittstelle aufgerufen wird, übersetzt es den Fehler möglicherweise in eine entsprechende Meldung, die dem Benutzer angezeigt wird, und so weiter. Der Punkt ist, dass diese Funktion nicht weiß, wie sie mit den Fehlern umgehen soll, die möglicherweise ausgelöst werden.

Das Wesen meiner Verwirrung ist, dass es zum Testen einer solchen Funktion in einer Einheit notwendig erscheint, die genaue Implementierung im Test selbst zu wiederholen (indem angegeben wird, dass Methoden in einer bestimmten Reihenfolge auf Mocks angewendet werden), und dass dies falsch erscheint.

Sollte savePeople()das Gerät getestet werden? Ja. Sie testen nicht, ob das dataStore.savePersonfunktioniert oder ob die Datenbankverbindung funktioniert oder ob es überhaupt foreachfunktioniert. Sie testen, dass savePeopledas Versprechen, das es durch seinen Vertrag macht , erfüllt wird.

Stellen Sie sich dieses Szenario vor: Jemand überarbeitet die Codebasis grundlegend und entfernt versehentlich den forEachTeil der Implementierung, sodass immer nur das erste Element gespeichert wird. Möchten Sie nicht, dass ein Komponententest dies erfasst?

Normalerweise taucht diese Art von Frage auf, wenn Leute "Test-After" -Entwicklungen durchführen. Gehen Sie dieses Problem aus Sicht von TDD an, bei dem Tests vor der Implementierung durchgeführt werden, und stellen Sie sich diese Frage erneut als Übung.

Zumindest in meiner Anwendung von TDD, die normalerweise von außen nach innen ausgeführt wird, würde ich keine Funktion wie savePeoplenach der Implementierung implementieren savePerson. Die Funktionen savePeopleund savePersonwürden als eine Funktion beginnen und aus denselben Einheitentests heraus getestet werden. Die Trennung zwischen den beiden würde sich nach einigen Tests im Refactoring-Schritt ergeben. Diese Arbeitsweise würde auch die Frage aufwerfen, wo sich die Funktion befinden savePeoplesollte - ob es sich um eine freie Funktion oder einen Teil der Funktion handelt dataStore.

Am Ende würden die Tests nicht nur überprüfen , ob Sie richtig eine speichern kann Personin dem Store, aber auch viele Personen. Dies würde mich auch zu der Frage führen, ob andere Überprüfungen erforderlich sind, zum Beispiel: "Muss ich sicherstellen, dass die savePeopleFunktion atomar ist und entweder alle oder keine speichert?" Wie würden diese Fehler aussehen? "und so weiter. All dies ist viel mehr als nur die Überprüfung auf die Verwendung einer forEachoder anderer Formen der Iteration.

Wenn die Anforderung, mehr als eine Person auf einmal zu speichern, erst erfüllt wurde, nachdem sie erfüllt savePersonwurde, aktualisiere ich die vorhandenen Tests von savePerson, um die neue Funktion auszuführen savePeople, und stelle sicher, dass weiterhin eine Person gespeichert werden kann, indem zunächst einfach delegiert wird. Testen Sie dann das Verhalten für mehr als eine Person durch neue Tests und überlegen Sie, ob es notwendig wäre, das Verhalten atomar zu machen oder nicht.

Soll savePeople () Unit-getestet werden?

Ja, das sollte es. Versuchen Sie jedoch, Ihre Testbedingungen unabhängig von der Implementierung zu schreiben. Verwandeln Sie beispielsweise Ihr Verwendungsbeispiel in einen Komponententest:

function testSavePeople() {
    myDataStore = new Store('some connection string', 'password');
    myPeople = ['Joe', 'Maggie', 'John'];
    savePeople(myDataStore, myPeople);
    assert(myDataStore.containsPerson('Joe'));
    assert(myDataStore.containsPerson('Maggie'));
    assert(myDataStore.containsPerson('John'));
}

Dieser Test macht mehrere Dinge:

• es überprüft den Vertrag der Funktion savePeople()
• Es kümmert sich nicht um die Implementierung von savePeople()
• es dokumentiert die beispielhafte Verwendung von savePeople()

Beachten Sie, dass Sie den Datenspeicher weiterhin verspotten / stubben / fälschen können. In diesem Fall würde ich nicht nach expliziten Funktionsaufrufen suchen, sondern nach dem Ergebnis der Operation. Auf diese Weise ist mein Test auf zukünftige Änderungen / Refaktoren vorbereitet.

Beispielsweise könnte Ihre Datenspeicherimplementierung saveBulkPerson()in Zukunft eine Methode bereitstellen - jetzt würde eine Änderung der zu verwendenden Implementierung savePeople()den saveBulkPerson()Komponententest nicht abbrechen, solange dies saveBulkPerson()wie erwartet funktioniert. Und wenn saveBulkPerson()irgendwie nicht funktioniert wie erwartet, Ihr Gerät zu testen wird , dass fangen.

oder würde ein solcher Test das eingebaute forEach-Sprachkonstrukt testen?

Versuchen Sie, wie gesagt, die erwarteten Ergebnisse und die Funktionsschnittstelle zu testen, nicht die Implementierung (es sei denn, Sie führen Integrationstests durch - dann kann das Abfangen bestimmter Funktionsaufrufe hilfreich sein). Wenn es mehrere Möglichkeiten gibt, eine Funktion zu implementieren, sollten alle mit Ihrem Komponententest funktionieren.

In Bezug auf Ihre Aktualisierung der Frage:

Test auf Zustandsänderungen! ZB wird ein Teil des Teigs verwendet. Stellen Sie gemäß Ihrer Implementierung sicher, dass die verwendete Menge doughin die Menge passt, panoder dass die Menge doughaufgebraucht ist. Stellen Sie pannach dem Funktionsaufruf sicher, dass das Cookies enthält. Stellen Sie sicher, dass das ovenleer ist / sich im selben Zustand wie zuvor befindet.

Überprüfen Sie für zusätzliche Tests die Flankenfälle: Was passiert, wenn die ovenvor dem Anruf nicht leer ist? Was passiert, wenn nicht genug da ist dough? Ist der panschon voll?

Sie sollten in der Lage sein, alle erforderlichen Daten für diese Tests aus den Objekten Teig, Pfanne und Ofen selbst abzuleiten. Die Funktionsaufrufe müssen nicht erfasst werden. Behandeln Sie die Funktion so, als stünde Ihnen ihre Implementierung nicht zur Verfügung!

Tatsächlich schreiben die meisten TDD-Benutzer ihre Tests, bevor sie die Funktion schreiben, sodass sie nicht von der tatsächlichen Implementierung abhängig sind.

Für Ihre neueste Ergänzung:

Wenn ein Benutzer ein neues Konto erstellt, müssen einige Dinge geschehen: 1) Ein neuer Benutzerdatensatz muss in der Datenbank erstellt werden. 2) Eine Begrüßungs-E-Mail muss gesendet werden. 3) Die IP-Adresse des Benutzers muss für Betrugsfälle aufgezeichnet werden Zwecke.

Deshalb möchten wir eine Methode erstellen, die alle Schritte "Neuer Benutzer" miteinander verbindet:

function createNewUser(validatedUserData, emailService, dataStore) {
    userId = dataStore.insertUserRecord(validateduserData);
    emailService.sendWelcomeEmail(validatedUserData);
    dataStore.recordIpAddress(userId, validatedUserData.ip);
}

Für eine Funktion wie diese würde ich die Parameter dataStoreund verspotten / stub / fake (was auch immer allgemeiner erscheint) emailService. Diese Funktion führt keine Zustandsübergänge für einen Parameter aus, sondern delegiert sie an Methoden einiger von ihnen. Ich würde versuchen, zu überprüfen, dass der Aufruf der Funktion 4 Dinge tat:

• Es wurde ein Benutzer in den Datenspeicher eingefügt
• Es hat eine Begrüßungs-E-Mail gesendet (oder zumindest die entsprechende Methode aufgerufen)
• Es zeichnete die IP des Benutzers im Datenspeicher auf
• Es hat alle aufgetretenen Ausnahmen / Fehler delegiert (falls vorhanden).

Die ersten drei Prüfungen können mit Schein, Stich oder Fälschung von dataStoreund durchgeführt werden emailService(Sie möchten beim Testen wirklich keine E-Mails senden). Da ich dies für einige der Kommentare nachschlagen musste, sind dies die Unterschiede:

• Eine Fälschung ist ein Objekt, das sich wie das Original verhält und bis zu einem gewissen Grad nicht zu unterscheiden ist. Sein Code kann normalerweise über Tests hinweg wiederverwendet werden. Dies kann beispielsweise eine einfache speicherinterne Datenbank für einen Datenbank-Wrapper sein.
• Ein Stub implementiert nur so viel wie nötig, um die für diesen Test erforderlichen Operationen auszuführen. In den meisten Fällen ist ein Stub spezifisch für einen Test oder eine Testgruppe, für die nur ein kleiner Satz der Methoden des Originals erforderlich ist. In diesem Beispiel könnte es sich um eine handeln dataStore, die nur eine geeignete Version von insertUserRecord()und implementiert recordIpAddress().
• Ein Mock ist ein Objekt, mit dem Sie überprüfen können, wie es verwendet wird (in den meisten Fällen können Sie Aufrufe seiner Methoden auswerten). Ich würde versuchen, sie in Komponententests sparsam zu verwenden, da Sie mit ihnen tatsächlich versuchen, die Funktionsimplementierung und nicht die Einhaltung der Schnittstelle zu testen, aber sie haben immer noch ihre Verwendung. Es gibt viele Modell-Frameworks, mit denen Sie genau das Modell erstellen können, das Sie benötigen.

Beachten Sie, dass, wenn eine dieser Methoden einen Fehler auslöst, der Fehler in den aufrufenden Code aufsteigen soll, damit er den Fehler nach Belieben behandeln kann. Wenn er vom API-Code aufgerufen wird, übersetzt er den Fehler möglicherweise in einen geeigneten HTTP-Antwortcode. Wenn es von einer Webschnittstelle aufgerufen wird, übersetzt es den Fehler möglicherweise in eine entsprechende Meldung, die dem Benutzer angezeigt wird, und so weiter. Der Punkt ist, dass diese Funktion nicht weiß, wie sie mit den Fehlern umgeht, die möglicherweise ausgelöst werden.

Erwartete Ausnahmen / Fehler sind gültige Testfälle: Sie bestätigen, dass sich die Funktion in einem solchen Fall wie erwartet verhält. Dies kann erreicht werden, indem das entsprechende Schein- / Fälschungs- / Stichobjekt geworfen wird, wenn dies gewünscht wird.

Das Wesen meiner Verwirrung ist, dass es zum Testen einer solchen Funktion in einer Einheit notwendig erscheint, die genaue Implementierung im Test selbst zu wiederholen (indem angegeben wird, dass Methoden in einer bestimmten Reihenfolge auf Mocks angewendet werden), und dass dies falsch erscheint.

Manchmal muss das gemacht werden (obwohl es Ihnen bei Integrationstests am wichtigsten ist). Häufiger gibt es andere Möglichkeiten, um die erwarteten Nebenwirkungen / Zustandsänderungen zu überprüfen.

Das Überprüfen der genauen Funktionsaufrufe führt zu eher spröden Komponententests: Nur kleine Änderungen an der ursprünglichen Funktion führen zum Fehlschlagen. Dies kann erwünscht sein oder nicht, erfordert jedoch eine Änderung der entsprechenden Komponententests, wenn Sie eine Funktion ändern (Refactoring, Optimierung, Fehlerbehebung, ...).

Leider verliert der Komponententest in diesem Fall etwas an Glaubwürdigkeit: Da er geändert wurde, bestätigt er die Funktion nicht, nachdem sich die Änderung wie zuvor verhalten hat.

Angenommen, jemand fügt oven.preheat()in Ihrem Beispiel für das Backen von Cookies einen Aufruf für (Optimierung!) Hinzu:

• Wenn Sie das Ofenobjekt verspottet haben, wird es diesen Aufruf nicht erwarten und den Test nicht bestehen, obwohl sich das beobachtbare Verhalten der Methode nicht geändert hat (Sie haben hoffentlich immer noch eine Pfanne mit Cookies).
• Ein Stub kann fehlschlagen oder nicht, je nachdem, ob Sie nur die zu testenden Methoden oder die gesamte Schnittstelle mit einigen Dummy-Methoden hinzugefügt haben.
• Eine Fälschung sollte nicht scheitern, da sie die Methode (entsprechend der Schnittstelle) implementieren sollte

Bei meinen Unit-Tests versuche ich, so allgemein wie möglich zu sein: Wenn sich die Implementierung ändert, aber das sichtbare Verhalten (aus Sicht des Aufrufers) immer noch dasselbe ist, sollten meine Tests bestanden werden. Im Idealfall sollte der einzige Fall, in dem ich einen vorhandenen Komponententest ändern muss, eine Fehlerbehebung sein (des Tests, nicht der getesteten Funktion).

Der primäre Wert, den ein solcher Test bietet, besteht darin, dass Ihre Implementierung überarbeitbar ist.

Ich habe in meiner Karriere viele Leistungsoptimierungen durchgeführt und häufig Probleme mit dem von Ihnen gezeigten Muster festgestellt: Um N Entitäten in der Datenbank zu speichern, führen Sie N Einfügungen durch. Normalerweise ist es effizienter, eine Masseneinfügung mit einer einzelnen Anweisung durchzuführen.

Andererseits wollen wir auch nicht vorzeitig optimieren. Wenn Sie in der Regel nur 1 bis 3 Personen gleichzeitig speichern, ist das Schreiben eines optimierten Stapels möglicherweise zu viel des Guten.

Mit einem ordnungsgemäßen Komponententest können Sie ihn so schreiben, wie Sie ihn oben implementiert haben. Wenn Sie feststellen, dass Sie ihn optimieren müssen, können Sie dies mit dem Sicherheitsnetz eines automatisierten Tests tun, um etwaige Fehler aufzufangen. Dies hängt natürlich von der Qualität der Tests ab. Testen Sie also großzügig und gut.

Der sekundäre Vorteil des Unit-Testens dieses Verhaltens besteht darin, dass es als Dokumentation für dessen Zweck dient. Dieses triviale Beispiel mag offensichtlich sein, aber im Hinblick auf den nächsten Punkt könnte es sehr wichtig sein.

Der dritte Vorteil, auf den andere hingewiesen haben, besteht darin, dass Sie verdeckte Details testen können, die mit Integrations- oder Abnahmetests nur sehr schwer zu testen sind. Wenn zum Beispiel die Anforderung besteht, dass alle Benutzer atomar gespeichert werden, können Sie einen Testfall dafür schreiben, der Ihnen Aufschluss über das erwartete Verhalten gibt und auch als Dokumentation für eine möglicherweise nicht offensichtliche Anforderung dient an neue Entwickler.

Ich werde einen Gedanken hinzufügen, den ich von einem TDD-Lehrer bekommen habe. Testen Sie die Methode nicht. Testen Sie das Verhalten. Mit anderen Worten, Sie testen nicht, dass dies savePeoplefunktioniert. Sie testen, dass mehrere Benutzer in einem einzigen Anruf gespeichert werden können.

Ich fand meine Fähigkeit Qualität Unit - Tests zu tun und TDD zu verbessern , wenn ich darüber nachzudenken , Unit - Tests gestoppt, Überprüfung, ob ein Programm funktioniert, sondern sie überprüfen, ob eine Einheit des Code tut , was ich erwarte . Das sind andere. Sie verifizieren nicht, dass es funktioniert, aber sie verifizieren, dass es das tut, was ich denke. Als ich anfing, so zu denken, änderte sich meine Perspektive.

Sollte bakeCookies()getestet werden? Ja.

Wie sollte eine Funktion wie diese Unit getestet werden, vorausgesetzt, Sie glauben, dass es sollte? Es fällt mir schwer, mir irgendeine Art von Unit-Test vorzustellen, bei dem Teig, Pfanne und Ofen nicht einfach nur verspottet werden und dann behauptet wird, dass Methoden für sie gelten.

Nicht wirklich. Schauen Sie sich genau an, WAS die Funktion tun soll - sie soll das ovenObjekt in einen bestimmten Zustand versetzen. Betrachtet man den Code, so scheint es, dass die Zustände der panund dough-Objekte nicht wirklich wichtig sind. Übergeben Sie also ein ovenObjekt (oder verspotten Sie es) und stellen Sie am Ende des Funktionsaufrufs fest, dass es sich in einem bestimmten Zustand befindet.

Mit anderen Worten, Sie sollten behaupten, dass bakeCookies()die Kekse gebacken haben .

Bei sehr kurzen Funktionen scheinen Komponententests nicht viel mehr zu sein als Tautologie. Aber vergessen Sie nicht, Ihr Programm wird viel länger dauern als die Zeit, in der Sie es schreiben. Diese Funktion kann sich in Zukunft ändern oder auch nicht.

Unit-Tests haben zwei Funktionen:

1. Es testet, dass alles funktioniert. Dies ist die am wenigsten nützliche Funktion, für die Unit-Tests durchgeführt werden, und es scheint, dass Sie diese Funktionalität nur bei der Frage berücksichtigen.

2. Es wird überprüft, ob zukünftige Änderungen des Programms die zuvor implementierte Funktionalität beeinträchtigen. Dies ist die nützlichste Funktion von Komponententests und verhindert die Einführung von Fehlern in große Programme. Es ist nützlich beim normalen Codieren, wenn Features zum Programm hinzugefügt werden, aber es ist nützlicher beim Refactoring und bei Optimierungen, bei denen die Kernalgorithmen, die das Programm implementieren, dramatisch geändert werden, ohne das beobachtbare Verhalten des Programms zu ändern.

Testen Sie nicht den Code innerhalb der Funktion. Testen Sie stattdessen, ob die Funktion das tut, was sie sagt. Wenn Sie Unit-Tests auf diese Weise betrachten (Funktionen testen, nicht Code), werden Sie feststellen, dass Sie niemals Sprachkonstrukte oder gar Anwendungslogik testen. Sie testen eine API.

Sollte savePeople () Unit-getestet werden, oder würden solche Tests dem Testen des integrierten forEach-Sprachkonstrukts gleichkommen?

Ja. Aber Sie könnten es auf eine Weise tun, die das Konstrukt erneut testet.

Hier ist zu beachten, wie sich diese Funktion verhält, wenn ein savePersonFehler auf halbem Weg auftritt. Wie soll es funktionieren?

Das ist die Art subtilen Verhaltens, die die Funktion bietet, die Sie mit Unit-Tests erzwingen sollten.

Der Schlüssel hier ist Ihre Sicht auf eine bestimmte Funktion als Trivialität. Der größte Teil der Programmierung ist trivial: einen Wert zuweisen, etwas rechnen, eine Entscheidung treffen: Wenn dies dann der Fall ist, eine Schleife fortsetzen, bis ... Alle trivial. Sie sind gerade durch die ersten 5 Kapitel eines Buches gekommen, das eine Programmiersprache unterrichtet.

Die Tatsache, dass das Schreiben eines Tests so einfach ist, sollte ein Zeichen dafür sein, dass Ihr Design nicht so schlecht ist. Wünschen Sie ein Design, das nicht einfach zu testen ist?

"Das wird sich nie ändern." So beginnen die meisten gescheiterten Projekte. Ein Einheitentest bestimmt nur, ob die Einheit unter bestimmten Umständen wie erwartet funktioniert. Lass es passieren und dann kannst du die Implementierungsdetails vergessen und es einfach benutzen. Nutzen Sie diesen Gehirnraum für die nächste Aufgabe.

Zu wissen, dass die Dinge wie erwartet funktionieren, ist sehr wichtig und bei großen Projekten und insbesondere bei großen Teams nicht trivial. Wenn Programmierer eines gemeinsam haben, ist die Tatsache, dass wir uns alle mit dem schrecklichen Code eines anderen auseinandersetzen mussten. Das Mindeste, was wir tun können, sind einige Tests. Wenn Sie Zweifel haben, schreiben Sie einen Test und fahren Sie fort.

Sollte savePeople () Unit-getestet werden, oder würden solche Tests dem Testen des integrierten forEach-Sprachkonstrukts gleichkommen?

Dies wurde bereits von @BryanOakley beantwortet, aber ich habe einige zusätzliche Argumente (denke ich):

Zunächst dient ein Unit-Test zum Testen der Vertragserfüllung und nicht der Implementierung einer API. Der Test sollte Vorbedingungen setzen, dann aufrufen und auf Auswirkungen, Nebenwirkungen, etwaige Invarianten und Post-Bedingungen prüfen. Wenn Sie entscheiden, was getestet werden soll, spielt die Implementierung der API keine Rolle (und sollte es auch nicht sein) .

Zweitens wird Ihr Test dort sein, um die Invarianten zu überprüfen, wenn sich die Funktion ändert . Die Tatsache, dass es sich jetzt nicht ändert, bedeutet nicht, dass Sie den Test nicht haben sollten.

Drittens ist es wertvoll, einen trivialen Test sowohl in einem TDD-Ansatz (der ihn vorschreibt) als auch außerhalb davon implementiert zu haben.

Beim Schreiben von C ++ neige ich dazu, für meine Klassen einen einfachen Test zu schreiben, der ein Objekt instanziiert und Invarianten überprüft (zuweisbar, regulär usw.). Ich fand es überraschend, wie oft dieser Test während der Entwicklung unterbrochen wurde (zum Beispiel durch versehentliches Hinzufügen eines nicht beweglichen Elements in einer Klasse).

Ich denke, Ihre Frage lautet:

Wie teste ich eine Void-Funktion, ohne dass es sich um einen Integrationstest handelt?

Wenn wir zum Beispiel Ihre Cookie-Backfunktion so ändern, dass Cookies zurückgegeben werden, wird sofort klar, wie der Test aussehen soll.

Wenn wir pan.GetCookies aufrufen müssen, nachdem wir die Funktion aufgerufen haben, können wir uns fragen, ob es sich wirklich um einen Integrationstest handelt oder ob wir nicht nur das pan-Objekt testen.

Ich denke, Sie haben Recht damit, dass Unit-Tests mit allem, was verspottet wurde, und nur die Überprüfung der Funktionen xy und z als Mangelwert bezeichnet wurden.

Aber! Ich würde argumentieren, dass Sie in diesem Fall Ihre Void-Funktionen überarbeiten sollten, um ein testbares Ergebnis zurückzugeben, ODER reale Objekte verwenden und einen Integrationstest durchführen sollten

--- Update für das createNewUser-Beispiel

• In der Datenbank muss ein neuer Benutzerdatensatz erstellt werden
• Es muss eine Begrüßungs-E-Mail gesendet werden
• Die IP-Adresse des Benutzers muss zu Betrugszwecken aufgezeichnet werden.

OK, diesmal wird das Ergebnis der Funktion nicht einfach zurückgegeben. Wir wollen den Zustand der Parameter ändern.

Hier werde ich etwas kontrovers. Ich erstelle konkrete Mock-Implementierungen für die Stateful-Parameter

Bitte, liebe Leser, versuchen Sie, Ihre Wut unter Kontrolle zu halten!

damit...

var validatedUserData = new UserData(); //we can use the real object for this
var emailService = new MockEmailService(); //a simple mock which saves sentEmails to a List<string>
var dataStore = new MockDataStore(); //a simple mock which saves ips to a List<string>

//run the test
target.createNewUser(validatedUserData, emailService, dataStore);

//check the results
Assert.AreEqual(1, emailService.EmailsSent.Count());
Assert.AreEqual(1, dataStore.IpsRecorded.Count());
Assert.AreEqual(1, dataStore.UsersSaved.Count());

Dies trennt das Implementierungsdetail der zu testenden Methode vom gewünschten Verhalten. Eine alternative Implementierung:

function createNewUser(validatedUserData, emailService, dataStore) {
  userId = dataStore.bulkInsedrtUserRecords(new [] {validateduserData});
  emailService.addEmailToQueue(validatedUserData);
  emailService.ProcessQueue();
  dataStore.recordIpAddress(userId, validatedUserData.ip);
}

Wird immer noch den Unit-Test bestehen. Außerdem haben Sie den Vorteil, dass Sie die Scheinobjekte testübergreifend wiederverwenden und sie für UI- oder Integrationstests in Ihre Anwendung einfügen können.

Sie sollten auch testen bakeCookies- was würde / sollte e..g bakeCookies(egg, pan, oven)ergeben? Spiegelei oder eine Ausnahme? Weder für sich pannoch für sich ovenselbst interessieren die eigentlichen Zutaten, da keiner von ihnen eigentlich bakeCookiesKekse liefern sollte, sondern soll. Im Allgemeinen kann es davon abhängen, wie doughes beschafft wird und ob die Chance besteht, dass es einfach wird eggoder z water. B. stattdessen.