Sollten Python Unit Tests in einem separaten Modul sein?

Question

Gibt es einen Konsens über den besten Ort, um Python-Unittests zu platzieren?

Sollten die Komponententests innerhalb des gleichen Moduls enthalten sein wie die getestete Funktionalität (wird ausgeführt, wenn das Modul alleine ausgeführt wird (if __name__ == '__main__', usw.)), oder ist es besser, die Komponententests in verschiedene Module zu integrieren? Ist eine Kombination beider Ansätze am besten, einschließlich Modulebene-Tests innerhalb jedes Moduls und Hinzufügung von Tests auf höherer Ebene, die Funktionalität in mehr als einem Modul als separate Module testen (vielleicht in einem Unterverzeichnis/test?).

Ich gehe davon aus, dass die Testentdeckung einfacher ist, wenn die Tests in separaten Modulen enthalten sind, aber es gibt eine zusätzliche Belastung für den Entwickler, wenn er daran denken muss, das zusätzliche Testmodul zu aktualisieren, wenn das zu testende Modul geändert wird.

Ich wäre daran interessiert, die Gedanken der Menschen über die beste Art der Organisation von Unit Tests zu wissen.

Answer 1

1. Wo Sie müssen, wenn eine Bibliothek mit Angabe, wo Unittests leben sollen,
2. in den Modulen selbst für kleine Projekte oder
3. in einem tests/ Unterverzeichnis in Ihrem Paket für größere Projekte.

Es ist eine Frage, was am besten für das Projekt funktioniert, das Sie erstellen.

Manchmal sind die Bibliotheken, die Sie bestimmen, verwenden, wo Tests gehen sollte, wie es der Fall mit Django (wo Sie Ihre Tests setzen in models.py, tests.py oder ein tests/ Unterverzeichnis in Ihrer Apps).

Wenn keine Einschränkungen vorhanden sind, ist dies eine Frage der persönlichen Präferenz. Bei einem kleinen Satz von Modulen ist es möglicherweise bequemer, die Komponententests in die von Ihnen erstellten Dateien einzufügen.

Für etwas mehr als ein paar Module erstelle ich die Tests separat in einem tests/ Verzeichnis im Paket. Wenn der Testcode mit der Implementierung gemischt wird, wird für jeden, der den Code liest, unnötiges Rauschen hinzugefügt.

Answer 2

Persönlich, ich erstelle einen Tests/Ordner in meinem Quellverzeichnis und versuche, mehr oder weniger, spiegeln meine wichtigsten Quellcode-Hierarchie mit Einheit Testäquivalente (mit 1 Modul = 1 Einheit Testmodul als Faustregel).

Beachten Sie, dass ich nose verwende und seine Philosophie ist ein bisschen anders als Unittests.

Answer 3

Ich halte den Testcode in der Regel in einem separaten Modul und versende das Modul/Paket und die Tests in einer einzigen Distribution. Wenn der Benutzer setup.py installiert, kann er die Tests aus dem Testverzeichnis ausführen, um sicherzustellen, dass alles in seiner Umgebung funktioniert, aber nur der Code des Moduls endet unter Lib/site-packages.

Answer 4

if __name__ == '__main__' usw. ist ideal für kleine Tests.

Answer 5

Möglicherweise gibt es andere Gründe als die Verwendung der if __name__ == '__main__' Prüfung. Wenn Sie die Tests in anderen Modulen beibehalten, bleibt diese Option für Sie offen. Außerdem - wenn Sie die Implementierung eines Moduls umgestalten und Ihre Tests in einem anderen Modul sind, das nicht bearbeitet wurde - wissen Sie, dass die Tests nicht geändert wurden, wenn Sie sie mit dem umgestalteten Code ausführen.

Answer 6

Ich habe sie in der Regel in einem separaten Ordner genannt am häufigsten test/. Persönlich verwende ich nicht die Prüfung if __name__ == '__main__', weil ich nosetests verwende und die Test-Erkennung selbst übernimmt.

Answer 7

JA, verwenden Sie ein separates Modul.

Es macht keinen Sinn, den __main__ Trick zu verwenden. Nehmen wir an, Sie haben mehrere Dateien in Ihrem Modul, und es funktioniert nicht mehr, weil Sie nicht jede Quelldatei separat beim Testen Ihres Moduls ausführen möchten.

Außerdem, wenn Sie ein Modul installieren, die meiste Zeit möchten Sie die Tests nicht installieren. Ihr Endanwender interessiert sich nicht für Tests, nur die Entwickler sollten sich darum kümmern.

Nein, wirklich. Setzen Sie Ihre Tests in tests/, Ihr Dokument in doc, und haben Sie ein Makefile bereit für eine make test. Alle anderen Ansätze sind nur Zwischenlösungen, die nur für bestimmte winzige Module gelten.