Unkritische Unittest-Fehler

Question

Ich verwende Pythons eingebaute unittest Modul und ich möchte ein paar Tests schreiben, die nicht kritisch sind.

Ich meine, wenn mein Programm solche Tests besteht, ist das großartig! Wenn es aber nicht besteht, ist das nicht wirklich ein Problem, das Programm wird trotzdem funktionieren.

Mein Programm soll zum Beispiel mit einem benutzerdefinierten Typ "A" funktionieren. Wenn es mit "A" nicht funktioniert, dann ist es kaputt. Der Einfachheit halber sollte das meiste jedoch auch mit einem anderen Typ "B" funktionieren, aber das ist nicht zwingend. Wenn es mit "B" nicht funktioniert, dann ist es nicht kaputt (weil es immer noch mit "A" funktioniert, was sein Hauptzweck ist). Wenn es mit "B" nicht funktioniert, ist das nicht kritisch, ich verpasse dann nur eine "Bonusfunktion", die ich haben könnte.

Ein weiteres (hypothetisches) Beispiel ist das Schreiben einer OCR. Der Algorithmus sollte die meisten Bilder aus den Tests erkennen, aber es ist in Ordnung, wenn einige von ihnen nicht erkannt werden. (und nein, ich schreibe keine OCR)

Gibt es eine Möglichkeit, nicht-kritische Tests in Unittest (oder einem anderen Test-Framework) zu schreiben?

Answer 1

In Python 2.7 (und 3.1) wurde die Unterstützung für das Überspringen einiger Testmethoden oder Testfälle sowie die Markierung einiger Tests als erwartetes Scheitern .

http://docs.python.org/library/unittest.html#skipping-tests-and-expected-failures

Tests, die als erwarteter Fehlschlag gekennzeichnet sind, werden nicht als Fehlschlag in einem TestResult gezählt.

Answer 2

Es gibt einige Testsysteme, die Warnungen anstelle von Fehlern zulassen, aber test_unit gehört nicht dazu (ich weiß nicht, welche das tun), es sei denn, Sie wollen es erweitern (was möglich ist).

Sie können die Tests so gestalten, dass sie Warnungen protokollieren, anstatt fehlzuschlagen.

Eine andere Möglichkeit, damit umzugehen, besteht darin, die Tests zu trennen und sie nur auszuführen, um die Pass/Fail-Berichte zu erhalten und keine Build-Abhängigkeiten zu haben (dies hängt von Ihrer Build-Einrichtung ab).

Answer 3

Werfen Sie einen Blick auf Nose : http://somethingaboutorange.com/mrl/projects/nose/0.11.1/

Es gibt zahlreiche Befehlszeilenoptionen für die Auswahl der auszuführenden Tests, und Sie können Ihre vorhandenen Unittest-Tests beibehalten.

Answer 4

Eine andere Möglichkeit ist es, einen "B"-Zweig zu erstellen (Sie verwenden irgendeine Art von Versionskontrolle, richtig?) und Ihre Unit-Tests für "B" darin zu haben. Auf diese Weise halten Sie Ihre Release-Version Unit-Tests sauber (Schauen Sie, alle Punkte!), aber immer noch Tests für B. Wenn Sie ein modernes Versionskontrollsystem wie Git oder Mercurial (ich bin teilweise auf Mercurial), Verzweigen/Klonen und Zusammenführen sind trivial Operationen, so dass das ist, was ich empfehlen würde.

Ich denke jedoch, dass Sie Tests für etwas verwenden, wofür sie nicht gedacht sind. Die eigentliche Frage lautet: "Wie wichtig ist es für Sie, dass 'B' funktioniert?" Denn Ihre Testsuite sollte nur Tests enthalten, bei denen es Ihnen wichtig ist, ob sie bestehen oder nicht. Tests, die, wenn sie fehlschlagen, bedeuten, dass der Code defekt ist. Aus diesem Grund habe ich vorgeschlagen, "B" nur im "B"-Zweig zu testen, da dies der Zweig ist, in dem Sie die "B"-Funktion entwickeln.

Wenn Sie möchten, können Sie die Befehle logger oder print verwenden. Aber wenn Sie sich nicht genug darum kümmern, dass es kaputt ist, um es in Ihren Unit-Tests zu markieren, würde ich ernsthaft in Frage stellen, ob Sie sich genug darum kümmern, es überhaupt zu testen. Außerdem führt das zu unnötiger Komplexität (zusätzliche Variablen zum Einstellen des Debug-Levels, mehrere Testvektoren, die völlig unabhängig voneinander sind, aber im selben Raum operieren, was zu potenziellen Kollisionen und Fehlern führt, usw.). Wenn Sie nicht gerade eine "Hello, World!"-Anwendung entwickeln, vermute ich, dass Ihre Problemstellung kompliziert genug ist, ohne zusätzliche, unnötige Komplikationen hinzuzufügen.

Answer 5

Sie könnten Ihre Tests so schreiben, dass sie die Erfolgsquote zählen. Bei OCR könnten Sie 1000 Bilder in den Code werfen und verlangen, dass 95 % erfolgreich sind.

Wenn Ihr Programm mit Typ A arbeiten muss, schlägt der Test fehl. Wenn es nicht erforderlich ist, mit B zu arbeiten, welchen Wert hat dann ein solcher Test?