Sollten wir Tests entfernen, die während des TDD

zu einfach zu brechen sind, habe ich versucht, den TDD-Ansatz beizubehalten. Also habe ich ein paar Tests gemacht, die alle scheitern. Jetzt implementiere ich. Aber jetzt, wo ich das implementiere, habe ich gesehen, dass die Methoden zu einfach sind, um zu versagen. Insbesondere habe ich das Beobachtermuster implementiert und alles, was passiert, ist, dass ich alle registrierten Beobachter benachrichtige. Verwenden Sie daher für jede Schleife eine und rufen Sie notify auf. Das klingt sicherlich zu einfach zu brechen. Jetzt wo ich die Tests an Orten habe, sollte ich sie löschen? Dies scheint auch eine Zeitverschwendung zu sein. Sollte ich also versuchen, Methoden zu antizipieren, die zu einfach wären zu brechen?Sollten wir Tests entfernen, die während des TDD

Quelle

2010-02-11 uriDium

Die Methoden zu einfach sein können, gerade jetzt zu brechen, sondern, dass sie (und möglicherweise gebrochen) in der Zukunft bedeutet nicht, nie geändert werden müssen, würden.

Quelle

2010-02-11 09:56:07

Danke für den Kommentar. Dann sollte ich sie lieber für jetzt lassen und sie später hinzufügen, wenn sich die Methode ändert. Offensichtliche Gefahr ist, dass Sie vergessen, den Komponententest zu aktualisieren. Aber selbst wenn wir Änderungen vornehmen, sollten wir zuerst einen Einheitentest für die Änderung schreiben müssen, damit wir ihn fangen können. – uriDium

Lassen Sie den einfachen Test dort, wenn die Methode geändert werden muss, und es ist eine brechende Änderung, dann müssen Sie die Komponententests ändern. Wenn es sich jedoch nicht um eine brechende Änderung handelt und die Tests nicht mehr funktionieren, liegt ein Fehler in Ihrer Änderung vor. –

Sie sagen, dass dies zu einfach ist zum Scheitern verurteilt:

for (i = 0; i < observers.length; ++i) { 
    // Notify observer observers[i] 
}

Es ist verlockend, dass, zu denken, aber diese häufigen Fehler betrachten:

for (i = 0; i <= observers.length; ++i) { 
    // Notify observer observers[i] 
}

Oder diese:

for (i = 0; i < observers.length; ++j) { 
    // Notify observer observers[i] 
}

Oder vielleicht werden Beobachter nicht richtig hinzugefügt. Oder ... oder ... oder ...

Wenn Sie bereits die Tests haben, scheint es nicht notwendig, sie zu entfernen, und ein Axiom der Software die Funktionen sind in der Regel im Laufe der Zeit wachsen, so etwas ist einfach jetzt ist vielleicht weniger online - genau die Art von Dingen, mit denen Ihre Tests Ihnen helfen sollen.

Quelle

2010-02-11 09:57:46

Nein für jede Aussage. Die For Each-Anweisung ist ein Sprachkonstrukt, sodass der Compiler im Wesentlichen RE-getestet wird. Wenn es eine normale Schleife mit int i = 0 usw. wäre, würde ich es tun. – uriDium

@uriDium: Das ist in Ordnung (Sie haben nicht angegeben, welche Sprache oder Konstrukt Sie verwendet haben, also ging ich mit einem gemeinsamen Nenner). Der Punkt steht immer noch; praktisch nichts ist zu einfach, um sich irgendwie zu irren, und Funktionen neigen dazu, im Laufe der Zeit an Komplexität zuzunehmen. –

@ T.J. Ich stimme zu, es mag keinen Sinn haben, foreach zu testen, aber Sie testen auch den Iterator-Block, der nicht zu einem benutzerdefinierten Iterator wird, er sollte natürlich eigene Tests haben, aber wer sagt das? Ich werde nichts finden, was diese Tests verpasst haben. –

Ja; Wenn Sie die Funktionalität des zugrunde liegenden Compilers/virtuellen Computers testen, ist Ihr Test zu einfach. Es sei denn, Sie vertrauen dem bestimmten Teil des Compilers/der virtuellen Maschine, der gerade ausgeführt wird, nicht.

Aber natürlich ist die Realität der Tests ein bisschen komplexer als nur eine Ja/Nein-Antwort auf diese Frage. Wenn Sie die Tests bereits geschrieben haben, löschen Sie sie nicht, wie in einer anderen Antwort erwähnt. Aber Sie sollten sie auch nicht in einem Code-Coverage-Kontext als Argument für das Vertrauen verwenden.

Quelle

2010-02-11 09:58:04 Steen

Sie tun es genau richtig: Schreiben von Tests, die zuerst versagen, Fixieren sie dann. Lassen Sie diese Tests in Ruhe, schreiben Sie komplexere in der Zukunft, wenn Sie denken, dass Sie sie benötigen (zB um Fehler zu reproduzieren).

Quelle

2010-02-11 10:01:09

Je mehr Tests Sie haben, desto weniger Schmerzen haben Sie in der Zukunft. Vergiss ihre Einfachheit.

Quelle

2010-02-11 10:01:20 Kerido

Nun, da Sie all diese Tests bestanden haben, lassen Sie sie in Ruhe. Wenn sie schnell genug laufen, sind sie für niemanden eine Belastung.

In Zukunft jedoch möchten Sie vielleicht nur eine Test auf einmal zu schreiben schreiben. (Siehe The Three Rules). Dies ist darauf zurückzuführen, dass Ihr Design verbessert werden kann, während Sie Ihren Code entwickeln.

Wenn Sie alle Ihre Tests fehlgeschlagen hatten und keine Implementierung hatten Sie Ihr Design repariert und jetzt funktioniert es Sie können es verabscheuen, das Design zu verbessern, um es zu verbessern.

Ich vermute auch, dass Sie eine knifflige Zeit hatten, Ihren Code zu implementieren, da jeder Implementierungsschritt möglicherweise mehr Tests als bestanden hat, aber hey, ich rate nur!

Quelle

2010-02-14 22:29:16 quamrana

Sollten wir Tests entfernen, die während des TDD

Antwort

Verwandte Themen