Was sind die Best Practices für Unit-Tests einer Bibliothek / eines Frameworks?

Kontext

Ich habe Mühe, eine Reihe von Komponententests für eine Bibliothek / ein Framework zu schreiben, das ich entwerfe. Stellen Sie sich meine Bibliothek im Kontext als Objektebene über einem hierarchischen Satz verwandter Objekte vor.

Frage

Grundsätzlich versuche ich, die Prinzipien und Best Practices in Bezug auf Unit-Tests einzuhalten, wie sie in zu sehen sindeinige Beiträge Hier, aber sie scheinen in Bezug auf das Testen einer Bibliothek oder eines Frameworks in Konflikt zu geraten.

Ein Basistest befasst sich beispielsweise mit dem Thema "Erstellen eines Artefakts". Und noch eine mit "Entfernen eines Artefakts". Da ein Komponententest jedoch eigenständig sein und den Zustand der Welt nach seiner Fertigstellung wiederherstellen soll, scheinen beide Tests in gewisser Weise miteinander verbunden zu sein: Wenn Sie die Artefakterstellung testen, müssen Sie den Zustand am Ende des Tests tatsächlich bereinigen es entfernen. Dies bedeutet, dass die Entfernung von Artefakten selbst implizit getestet wird. Dieselbe Überlegung gilt für das Testen der Entfernung von Artefakten: Um die Welt so einzurichten, dass die Entfernung von Artefakten testbar ist, müssen wir zuerst ein neues Artefakt erstellen.

Die Situation verschärft sich, wenn wir die Erzeugung und Entfernung von verwandten Unterartefakten in einer Einheit testen müssen, für die wir die Welt entsprechend einrichten müssen.

Ich neige dazu, eine Reihe zusammengehöriger Komponententests nacheinander durchzuführen, sodass jeder Komponententest diskret ist (d. H. Nur eine Sache und nur eine Sache testet), aber von vorherigen Tests in der Sequenz abhängt, um die Welt schrittweise einzurichten. Dann könnte meine Sequenz so aussehen:

[Artefakt erstellen] -> [Unterartefakt erstellen] -> [Unterartefakt entfernen] -> [Artefakt entfernen]

Mit diesem Prinzip wird die gesamte Bibliothek / das gesamte Framework einer Komponententestung unterzogen, und der Zustand der Welt wird am Ende des gesamten Durchlaufs der Testsuite wiederhergestellt. Dies bedeutet jedoch, dass jeder Fehler in der Mitte der Testsuite "die Welt bricht".

Welche bewährten Methoden und Richtlinien können hilfreich sein, um diese widersprüchlichen Anforderungen in Einklang zu bringen?

Verweise

Was macht einen guten Komponententest aus?

Ist es eine schlechte Form, einen Komponententest zu haben, der andere Komponententests aufruft?

Antworten auf die Frage(6)

Ihre Antwort auf die Frage