Vor kurzem hatte ich eine interessante Diskussion mit einem Kollegen über Einheitstests. Wir diskutierten darüber, wann die Pflege von Unit-Tests weniger produktiv wird, wenn sich Ihre Verträge ändern.
Vielleicht kann mir jemand erklären, wie ich dieses Problem angehen kann. Lassen Sie mich das näher ausführen:
Nehmen wir also an, es gibt eine Klasse, die einige raffinierte Berechnungen durchführt. Der Vertrag besagt, dass sie eine Zahl berechnen soll, oder sie gibt -1 zurück, wenn sie aus irgendeinem Grund fehlschlägt.
Ich habe Vertragstests, die das prüfen. Und bei all meinen anderen Tests verwende ich dieses raffinierte Taschenrechner-Dingsbums.
So, jetzt ändere ich den Vertrag, wenn es nicht berechnen kann, wird es eine CannotCalculateException werfen.
Meine Vertragstests werden fehlschlagen, und ich werde sie entsprechend korrigieren. Aber alle meine mocked/stubbed Objekte werden noch die alten Vertragsregeln verwenden. Diese Tests werden erfolgreich sein, während sie nicht sollten!
Die Frage, die sich stellt, ist, wie viel Vertrauen in solche Änderungen gesetzt werden kann, wenn man so sehr auf Unit-Tests vertraut... Die Unit-Tests sind erfolgreich, aber beim Testen der Anwendung werden Fehler auftreten. Die Tests, die mit diesem Rechner durchgeführt werden, müssen korrigiert werden, was Zeit kostet und vielleicht sogar mehrmals gestoppt/gespottet werden muss...
Wie denken Sie über diesen Fall? Ich habe nie gründlich darüber nachgedacht. Meiner Meinung nach wären diese Änderungen an den Unit-Tests akzeptabel. Wenn ich keine Unit-Tests verwende, würde ich auch sehen, dass solche Fehler in der Testphase (durch Tester) entstehen. Ich bin jedoch nicht zuversichtlich genug, um sagen zu können, was mehr (oder weniger) Zeit kosten wird.
Haben Sie eine Idee?
