Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
| Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung Nächste Überarbeitung | Vorherige Überarbeitung | ||
| talit:python_testing [2024-03-04 14:17] – [Sorting Example] hof | talit:python_testing [2024-03-04 14:38] (aktuell) – [Pytest] hof | ||
|---|---|---|---|
| Zeile 8: | Zeile 8: | ||
| Ein _Unit Test_ überprüft die Funktionsweise eines Moduls ($\approx$ einer Python-Datei). | Ein _Unit Test_ überprüft die Funktionsweise eines Moduls ($\approx$ einer Python-Datei). | ||
| + | |||
| ### Sorting Example | ### Sorting Example | ||
| Zeile 36: | Zeile 37: | ||
| Die `assert` Anweisung (ohne Klammern!) überprüft, | Die `assert` Anweisung (ohne Klammern!) überprüft, | ||
| - | Wir führen den Test aus mit `python test_sorting` - scheint alles in Ordnung zu sein. | + | Wir führen den Test aus mit `python test_sorting.py` - scheint alles in Ordnung zu sein. |
| ### Test Driven Development | ### Test Driven Development | ||
| Zeile 42: | Zeile 43: | ||
| Im Test-Driven-Development suchen wir nicht zuerst den Fehler, sondern schreiben zuerst einen neuen Test-Case, der den Fehler reproduziert (also beim Test-Durchlauf fehlschlägt). Erst dann flicken wir den fehlerhaften Code, bis alle Tests wieder grün sind. | Im Test-Driven-Development suchen wir nicht zuerst den Fehler, sondern schreiben zuerst einen neuen Test-Case, der den Fehler reproduziert (also beim Test-Durchlauf fehlschlägt). Erst dann flicken wir den fehlerhaften Code, bis alle Tests wieder grün sind. | ||
| - | |||
| #### Aufgabe A | #### Aufgabe A | ||
| Schreibe einen Test-Case für den rapportierten Fehler. Flicke anschliessend die `is_sorted` Funktion, bis alle Tests wieder durchlaufen. | Schreibe einen Test-Case für den rapportierten Fehler. Flicke anschliessend die `is_sorted` Funktion, bis alle Tests wieder durchlaufen. | ||
| + | ### Pytest | ||
| + | Um in grösseren Projekten nicht den Überblick zu verlieren, ist es Usus, ein Test-Framework zu verwenden, um alle Tests im Projekt auszuführen. Die beste Wahl für Python ist [[https:// | ||
| + | |||
| + | Installation: | ||
| + | |||
| + | Pytest sucht überall im Ordner nach Dateien, die mit `test_` beginnen, und führt darin alle Funktionen aus, die mit dem gleichen Präfix `test_` anfangen. | ||
| + | |||
| + | Wir müssen dafür also unseren Test leicht verändern: | ||
| + | |||
| + | <code python test_sorting.py> | ||
| + | from sorting import * | ||
| + | |||
| + | def test_sorted(): | ||
| + | assert is_sorted([' | ||
| + | assert not is_sorted([' | ||
| + | |||
| + | |||
| + | def test_sorted_bug(): | ||
| + | assert not is_sorted([' | ||
| + | </ | ||
| + | |||
| + | Die Ausführung von `pytest` findet die Datei und die zwei Testfunktionen und fasst die Resultate zusammen: | ||
| + | |||
| + | <code bash> | ||
| + | $ pytest | ||
| + | ============================================= test session starts ============================================== | ||
| + | platform darwin -- Python 3.11.7, pytest-8.1.0, | ||
| + | rootdir: / | ||
| + | collected 2 items | ||
| + | |||
| + | test_sorted.py .. [100%] | ||
| + | |||
| + | ============================================== 2 passed in 0.00s =============================================== | ||
| + | </ | ||
| + | |||
| + | Pytest wird auch von VSCode unterstützt (ev. muss in der Sidebar die _Tests_-Ansicht geöffnet werden: | ||
| + | |||
| + | {{: | ||
| + | |||
| + | #### Aufgabe B | ||
| + | |||
| + | Ändere deinen Unit-Test, damit er von pytest gefunden wird, und führe die Tests im Terminal und auch in VSCode aus. | ||
| ## Integration Tests | ## Integration Tests | ||