buhtz hat geschrieben: 
24.03.2022 12:33:47
paedubucher hat geschrieben: 24.03.2022 09:24:54
spuckt offenbar HTML aus, aber könnte es sein, dass hierzu andere Funktionen verwendet werden, die auf einer tieferen Ebene operieren? Vielleicht könntest du mit deinen Tests etwas tiefer ansetzen.
Das ist ein sehr guter Einwand. Und du hast Recht, da sind Funktionen die einzelne Elemente des Gesamt-HTML generieren. Die bekommen natürlich auch ihren Test. Das beschriebene Problem besteht aber auch hier. Dass schließt aber nicht die Verpflichtung aus, am Ende auch das große Ganze (z.B. den Zusammenbau) zu testen.
Es ist natürlich schon sinnvoll, alle Ebenen zu testen. Die Frage ist aber, ob du so nicht auf der obersten Ebene noch die Sachen mittestest, die du weiter unten schon getestet hast. Idealerweise soll die "höhere" Testfunktion ja nur die Aspekte testen, die deine produktive Funktion zusammenbringt. Und wenn du irgendwo einen Bug einfügst, sollte idealerweise auch nur ein einziger Test scheitern. Eine Funktion von automatisierten Tests ist nämlich auch das schnelle Lokalisieren von Fehlerursachen.
Da ich den Code nicht kenne, kann ich nur spekulieren. Evtl. musst du auch nicht den ganzen String vergleichen, sondern kannst dir bestehende Aspekte daraus rausgreifen, indem du etwa überprüfst ob das (gestrippte) Dokument mit
<!DOCTYPE html> anfängt (oder wie auch immer es bei dir sein muss), und dass es mit
</html> aufhört.
Eine ganz andere Möglichkeit wäre es, wenn du das HTML-Dokument nicht als String sondern als baumartige Struktur aufbaust. Das Rendern kannst du dann auf der Stufe der einzelnen Elemente testen. Die Baumstruktur kannst du dann per Unittest durchtesten. Hier wären natürlich ein paar Informationen hilfreich, was denn dein spezifischer Code genau so macht.
buhtz hat geschrieben:
paedubucher hat geschrieben: 24.03.2022 09:24:54
pytest ist auch recht schlank und macht v.a. deinen Testcode schlanker
)
OK, ich habe Pytest noch nicht eingesetzt, viele Bespiele gesehen, aber so recht erschließt sich mir nicht der Sinn. Das für mich wirksamste Argument ist bisher, dass pytest sich mehr an objektorientierung und Pythonkonzepten orientiert. Unittest stammt ja wohl irgendwie aus der Java Welt oder so ähnlich.
Pytest ist eher etwas sparsamer was OOP angeht, bzw. verlangt es nicht von dir, (Test)Klassen zu schreiben. Du kannst auch nur einzelne Funktionen schreiben und darin mit
assert arbeiten. Unittest ist dasjenige, das sich an JUnit orientiert. Das ganze setup/teardown-Konzept stammt von da. Die API von JUnit hat sich in den letzten ca. 20 Jahren doch recht stark gewandelt, sodass die Python Unittests mich mittlerweile stärker an meine alten Java-Tage erinnern als gegenwärtiger JUnit-Testcode
buhtz hat geschrieben:
Dennoch ist Pytest nicht Standard, weil es nicht mit Python geliefert wird. Deswegen ist die Nutzung von unittest schlanker, als die von pytest. Testcode muss nicht schlank i.S. von wenig Zeilen sein. Auch viele Zeilen kann man lesbar und wartbar gestalten. Unter Umstände sind viele Zeilen, sogar aussagekräftiger als weniger.
Wenn Python das pytest mal als inbuild Paket übernimmt, wovon ich ausgehe, lasse ich mich gerne darauf ein.
Pytest dürfte wohl kaum Pythons Standard werden. Die Codemenge wird aufgrund des geringeren (objektorientierten) Overheads schlanker. Der eigentliche Testcode, der auch den dokumentierenden Charakter hat, bleibt wohl in etwa gleich lange. Mit Pytest kannst du auch die bestehenden Unittests mitausführen, ohne dass du dafür etwas spezielles tun musst.
Ich persönlich bereue den Umstieg nicht. Aber ob Pytest oder Unittest ist ja hier nicht das Hauptproblem...
