der ultimative unittest loader/runner...

[jens]

Ich nutzte das unittest modul aus der Standard-Lib.

Möchte gern, das es:
* von "setup.py" läuft: alle tests: "./setup.py test" und auch bsp.: "./setup.py test ModuleFoo.test_bar"
* direkt Laufbar alle: "python ./tests/runtests.py" bzw.: "python ./tests/runtests.py ModuleFoo.test_bar"
* indirekt Laufbar, bsp: "python -m unittest discover"

Hinzu kommt, das ich gern die normalen Argumente wie --verbose, --failfast unterstützen möchte...

Sehe irgendwie keine Möglichkeit dazu, ohne viel eigenen Code zu schreiben. Dabei gibt es im Prinzip alles im unitest Modul.

z.B. sieht meine /tests/runtests.py so aus:

Code: Alles auswählen

import os
import unittest
import sys


if __name__ == "__main__":
    loader = unittest.TestLoader()

    start_dir = os.path.join(os.path.dirname(__file__))
    top_level_dir = os.path.join(start_dir, "..")
    suite = loader.discover(start_dir, top_level_dir=top_level_dir)

    runner = unittest.TextTestRunner(
        verbosity=2,
        # failfast=True,
    )
    result = runner.run(suite)
    sys.exit(len(result.errors) + len(result.failures))

Damit laufen aber immer alle Tests und die Argumente --verbose, --failfast usw. kann man auch nicht setzten.

[DasIch]

Dir ist schon klar wieso es pytest usw. gibt?

[BlackJack]

@jens: Das hatten wir doch so ähnlich neulich schon mal. Was genau passt Dir denn an `nose` oder `pytest` nicht? Soweit ich das sehe die beiden führenden Werkzeuge wenn man etwas möchte was die Standardbibliothek nicht abdeckt. Also zumindest mit im Gegensatz zum ”alten” `unittest` etwas das sich mehr nach Python und weniger nach Java anfühlt.

[jens]

Und welches von beiden nehmen?


Ich find es nur schade, weil eigentlich alles in unittest drin ist.

[BlackJack]

@jens: Laut Web soll `nose` besser sein wenn man schon `unittest`-Tests hat.

Ist in `unittest` tatsächlich alles drin? Ich habe mir `unittest2` noch nicht angeschaut, aber ich dachte bis jetzt immer das `py.test` und `nose` sowohl ”weniger” haben, nämlich Boilerplate wie `TestCase`-Klassen und diverse `assert*()`-Methoden, als auch mehr, zum Beispiel das man mit einer Generatorfunktion Testfälle generieren lassen kann.

[DasIch]

Ich find es nur schade, weil eigentlich alles in unittest drin ist.

Naja, kommt schon stark auf deine Definition von "alles" an und womit du bereit bist auszukommen. Gerade wenn man bereit ist sich komplett auf pytest einzulassen ist es meiner Meinung nach unittest weit überlegen.

[jens]

Also meistens hab ich ja Django Projekte und dabei kommt man mit unittest eigentlich gut aus.

[BlackJack]

@jens: Woher weisst Du das? Hast Du py.test oder nose mal umfangreich eingesetzt, oder *kennst* Du nur `unittest`? Dann hat die Aussage nicht so wirklich viel Gehalt.

[snafu]

Ich kann mir auch schlecht vorstellen, dass bei der Wahl des Test-Frameworks entscheidend ist, welche Bibliotheken man in seinem Projekt so verwendet. Das ist wohl eher eine Frage des persönlichen Geschmacks und der Anforderungen, die man an seine Tests stellt.

Ich selbst komme bisher auch ganz gut mit dem Unittest-Framework aus der Standardbibliothek aus. Welche Vorteile mir hierbei möglicherweise entgehen, kann ich dementsprechend nicht beurteilen. Ich habe aber auch kein allzu großes Verlangen nach einem Wechsel des Test-Frameworks.

[DasIch]

Der Vorteil sich an PEP 8 zu halten ist meiner Meinung nach schon mehr als Grund genug nicht unittest zu nutzen

[jens]

@jens: Laut Web soll `nose` besser sein wenn man schon `unittest`-Tests hat.

Danke für den Tip, ich glaube das ist der gesuchte "ultimative unittest loader/runner..."

[jens]

Mit nose funktionieren die DocTests nicht so richtig

Also starten möchte ich meine Tests gern mit:

Code: Alles auswählen

coverage run ./setup.py test

Denn ein ./setup.py test ist ja der "normale" Weg...

In diesem Fall, werden aber die DocTests nicht berücksichtigt.

Ich hab schon folgendes probiert:
In setup.py das gemacht:

Code: Alles auswählen

os.environ['NOSE_DOCTEST_EXTENSION'] = 'txt'
os.environ['NOSE_WITH_DOCTEST'] = 'True'
os.environ['NOSE_WITH_DOCTESTS'] = 'True'

Eine .noserc angelegt mit:

Code: Alles auswählen

[nosetests]
with-doctest=True

...und das selbe in setup.cfg eingefügt.


Hab auch mal ein issues gemacht: https://github.com/nose-devs/nose/issues/918

Letztlich habe ich dann in .travis.yml doch erstmal coverage run ./setup.py nosetests eingefügt...

[jens]

Nun hab ich mal versucht nose in einem django Projekt zu nutzten...

Hier scheint mir es allerdings ehr hinderlich, als förderlich zu sein.

Damit es etwas leichter wird, gibt es django-nose... Das habe ich auch probiert. Aber so richtig funktioniert das nicht:

Mein nicht funktionierender commit: https://github.com/jedie/django-secure- ... d5324dee25

[jens]

Der Vorteil sich an PEP 8 zu halten ist meiner Meinung nach schon mehr als Grund genug nicht unittest zu nutzen

Hab nochmal drüber nachgedacht...

Mittlerweile finde ich es als Vorteil

So kann man eigene assert_foo_bar() definieren und erkennt direkt an der Schreibweise, ob es eigene Sind.
Da Django die Schreibweise von unittest übernimmt, weiß man es auch da

[jens]

Vielleicht ist green auch ein Blick wert: https://github.com/CleanCut/green

[DasIch]

Schaut man sich die Origin Story von Green an würde ich mal sagen, es ist definitiv keinen Blick wert. Es existiert weil dem Autor die Ausgabe von den Alternativen nicht gefällt, wobei er sich pytest nicht ernsthaft angeschaut hat. Der Rest der README nennt kein einziges erwähnenswertes Feature, dass es gegenüber unittest abhebt. Schlimmernoch es erbt die hässlichen PEP8 verletztenden Namen. Entweder der Autor muss am Marketing nochmal etwas arbeiten oder green ist nur unittest in grün.

[jens]

Richtig scharf auf Farbliche Ausgabe bin ich nicht.

Mir geht es darum, das man ohne viel eigenen Code die Test laufen lassen kann. Da bietet unittest2 zu wenig. Nose hilft da weiter...

btw. die pep8 Geschichte sehe ich ja mittlerweile als Vorteil, siehe weiter oben.