Testgetriebene Entwicklung mit Pytest und PyCharm

Prinzipien der testgetriebenen Entwicklung

Testgetriebene Entwicklung basiert auf einem einfachen Zyklus: Zuerst wird ein Test für eine noch nicht-existierende Funktionalität geschrieben. Anschließend folgt eine minimalistische Implementierung, die gerade so ausreicht, um den Test zu bestehen. Danach wird der Code verbessert, ohne dass die Tests fehlschlagen. Dieser Ablauf wird als Red-Green-Refactor bezeichnet und wiederholt sich für jede neue Anforderung, wodurch eine robuste, gut getestete Codebasis entsteht. Tests fungieren dabei nicht nur als Qualitätssicherung, sondern dokumentieren gleichzeitig die erwartete Funktionalität einer Anwendung.

Ein häufiges Missverständnis bei TDD ist, dass eine hohe Testabdeckung automatisch zu höherer Softwarequalität führt. Tests können fehlerhaft sein oder unzureichend validieren, ob die Software tatsächlich korrekt funktioniert. Zudem erfordert testgetriebene Entwicklung Disziplin. Viele Entwickler beginnen mit dem Ansatz, kehren aber unter Zeitdruck oder sich schnell ändernden Anforderungen zu einer testarmen Entwicklung zurück.

Testen mit Pytest und PyCharm

Pytest erleichtert die testgetriebene Entwicklung durch eine minimalistische Syntax und zahlreiche Features. Tests sind leicht lesbar und werden automatisch erkannt, wenn ihre Namen mit test_ beginnen und sich in Dateien mit test_*.py befinden. Pytest bietet @pytest.mark.parametrize, um mehrere Testfälle effizient mit verschiedenen Eingaben und erwarteten Ausgaben durchzuführen:

import pytest
from calculator import add
@pytest.mark.parametrize("a, b, expected", [(1, 2, 3), (5, 5, 10), (-1, -2, -3)])
def test_add(a, b, expected):
    assert add(a, b) == expected

Pytest nutzt das native assert-Statement von Python, wodurch Tests intuitiver und leichter verständlich bleiben. Im Gegensatz dazu erfordert unittest spezifische Methoden wie assertEqual(a, b), was den Code oft unnötig aufbläht. Ein wesentlicher Vorteil von Pytest ist die detaillierte Fehlerausgabe: Wenn ein assert-Vergleich fehlschlägt, zeigt Pytest direkt die tatsächlichen und erwarteten Werte an. Dagegen liefert unittest meist nur eine allgemeine Fehlermeldung, sodass Entwickler manuell nach dem genauen Fehler suchen müssen. Das macht Pytest insbesondere bei komplexeren Tests effizienter.

Testen von Randfällen

Neben Standardfällen sollten auch Randfälle (Edge Cases) getestet werden, da sie häufig zu unerwarteten Fehlern führen. Zum Beispiel kann eine Division durch Null zu einer Exception führen:

def divide(a, b):
    if b == 0:
        raise ZeroDivisionError("Division durch Null ist nicht erlaubt")
    return a / b
def test_divide_by_zero():
    with pytest.raises(ZeroDivisionError):
        divide(10, 0)

Randfälle sind nicht nur mathematische Sonderfälle, sondern auch ungewöhnliche Eingaben, wie leere Listen, negative Zahlen oder sehr große Werte. Diese sollten durchdacht in Tests einbezogen werden.

Beispiel: Entwicklung eines String-Manipulators mit TDD

Ein Beispiel für testgetriebene Entwicklung ist die Entwicklung eines String-Manipulators, der Zeichenketten in Kleinbuchstaben umwandelt und bestimmte Muster entfernt. Nach dem Red-Green-Refactor-Prinzip startet ein Test zum Beispiel mit:

import pytest
from string_manipulator import StringManipulator
def test_convert_lowercase():
    manipulator = StringManipulator()
    assert manipulator.convert_lowercase("HELLO") == "hello"

Da die Methode convert_lowercase noch nicht existiert, schlägt der Test erwartungsgemäß fehl. Danach kann die Lösung implementiert werden:

class StringManipulator:
    def convert_lowercase(self, s: str) -> str:
        return s.lower()

Nach erneutem Testlauf besteht der Test. Doch der aktuelle Code ist noch nicht robust genug. Es fehlen Prüfungen für ungültige Eingaben. Der Test lässt sich für diese Prüfung aktualisieren:

def test_convert_lowercase_invalid_input():
    manipulator = StringManipulator()
    assert manipulator.convert_lowercase(123) == "Invalid input"
    assert manipulator.convert_lowercase(True) == "Invalid input"
    assert manipulator.convert_lowercase("") == "Input cannot be empty"

Jetzt muss die Methode angepasst werden, um solche Fälle abzufangen:

class StringManipulator:
    def convert_lowercase(self, s):
        if not isinstance(s, str):
            return "Invalid input"
        if not s:
            return "Input cannot be empty"
        return s.lower()

Durch dieses Vorgehen wird der Code schrittweise verbessert, indem zusätzliche Tests eingebunden werden, die potenzielle Fehlerfälle abdecken.

Mocking und seine Grenzen

Ein weiteres wichtiges Konzept ist Mocking, also das Simulieren von Abhängigkeiten mit unittest.mock. Das ist nützlich, wenn eine Funktion externe Services nutzt oder von einer Datenbank abhängt:

from unittest.mock import MagicMock
def test_external_service():
    service = MagicMock()
    service.get_data.return_value = {"id": 1, "value": "test"}
    assert service.get_data()["value"] == "test"

Mocking kann allerdings falsche Sicherheit vortäuschen. Wenn gemockte Objekte von der tatsächlichen Implementierung abweichen, kann es passieren, dass Tests erfolgreich laufen, obwohl das System in der Realität fehlschlägt. Daher sollten wichtige Integrationen zusätzlich mit echten Daten getestet werden.

Vergleich: Unittest versus Pytest

Während Unittest als Teil der Standardbibliothek weit verbreitet ist, bietet Pytest eine flexiblere und benutzerfreundlichere API. Hier ein Vergleich der beiden Ansätze:

Unittest

import unittest
from calculator import add
class TestCalculator(unittest.TestCase):
    def test_add(self):
        self.assertEqual(add(2, 3), 5)

Pytest

import pytest
from calculator import add
def test_add():
    assert add(2, 3) == 5

Pytest benötigt keine Klassenstruktur, nutzt assert für verständlichere Fehlermeldungen und bietet umfangreiche Erweiterungen wie Fixtures und Parametrisierung.

Ist testgetriebene Entwicklung noch sinnvoll?

Obwohl testgetriebene Entwicklung viele Vorteile bietet, gibt es auch Herausforderungen und Einschränkungen. Wenn sich Anforderungen oder Strukturen häufig ändern, müssen Tests kontinuierlich angepasst werden, was zusätzlichen Aufwand verursacht. In der explorativen Entwicklung kann testgetriebene Entwicklung hinderlich sein, da es strukturelle Entscheidungen zu früh festlegt. Tests sind zudem eng mit der aktuellen Codestruktur verknüpft, was größere Umstrukturierungen erschwert. Eine hohe Testabdeckung bedeutet nicht automatisch fehlerfreien oder gut strukturierten Code.

Besonders in agilen Umgebungen kann es vorkommen, dass Anforderungen ständig angepasst werden müssen. In diesen Fällen kann das blinde Festhalten an TDD dazu führen, dass mehr Zeit für das Anpassen von Tests als für die eigentliche Entwicklung aufgewendet wird. Stattdessen kann eine pragmatische Mischung aus explorativem Coding und nachträglichem Testen eine effizientere Lösung darstellen.