Testen von Implementierungen beenden

Testen von Implementierungen beenden

Eine Klasse, ein Test.

Einige von Ihnen mögen dieser Aussage zustimmen, und ich tat es früher auch. Jetzt tue ich das nicht mehr und bin für den Bruch dieser "Regel" gegeißelt worden.

Wir sollten aufhören, uns auf einen Test pro Klasse, Methode, Funktion oder was auch immer für ein technisches Konstrukt Ihrer Wahl zu fixieren - um das Ziel oder die Notwendigkeit einer Eins-zu-eins-Beziehung zwischen Tests und technischem Konstrukt zu erreichen.

Stattdessen sollten wir die Tests am Verhalten orientieren. Auf diese Weise wird das im Test spezifizierte Verhalten von der Implementierung entkoppelt, die es ausführt. Dadurch kann die Implementierung emergent und fließend sein. Der Test ist nicht an die Form der Lösung gekoppelt, sondern an das von ihr geforderte Verhalten.

Die Vorteile?

• Flexibilität. Wir erhöhen die Fähigkeit, die Umsetzung umzustrukturieren und gleichzeitig unser Sicherheitsnetz intakt zu halten.

• Entkopplung. Implementierung und Spezifikation (Test) müssen sich nicht im gleichen Tempo ändern. Das macht das Refactoring billiger, da wir nicht unbedingt beide Seiten der Gleichung ändern müssen.

• Verstehen. Der Verzicht auf das Testen der Implementierung und das Ausdrücken des Verhaltens führt dazu, dass Tests zu einer Spezifikation des Systems werden. Nicht in einem technischen, sondern in einem funktionalen Sinne. Sie enthalten weniger Rauschen in ihrer Geschichte, die das System erklärt.

Wie sind wir zu dieser 1:1-Beziehung zwischen Tests/Klassen gekommen? Das ist einfach und offensichtlich. Sich am Verhalten zu orientieren, erfordert tiefere Einsicht und Überlegungen, ähnlich wie das Verpacken von Code nach Anliegen im Gegensatz zu Typen. Es ist einfach, alle Ansichten in ein Paket zu packen, aber viel schwieriger, sie nach ihrer Änderungsrate (Kohäsion) zu gruppieren.

Ein weiterer Grund könnte sein, dass Unit-Tests schon immer ein zweideutiger Begriff waren. Die Leute suchen nach absoluten Regeln, wie z.B. eine Klasse, ein Test oder Mock-All-Collaborations. Die harte Wahrheit ist, dass es darauf ankommt. Harte Regeln sind nützlich, bis Sie mit zunehmender Erfahrung ein besseres Urteilsvermögen entwickeln, aber darüber hinaus verhindern sie die besten Ergebnisse von Kompromissen.

Die wichtigste Erkenntnis ist die folgende. Sehen Sie Tests nicht länger als Überprüfung Ihrer Implementierung an. Betrachten Sie sie als Spezifikation des Verhaltens, das Ihr System (teilweise) erreichen soll, und profitieren Sie von den Vorteilen.