Ein Angebot von

Unit Tests mit Python – Beispiele und Fallstricke

| Autor / Redakteur: Tobias Pleyer * / Sebastian Gerstl

Python hat sich als Mittel der Wahl bei Unit Tests weitgehend etabliert. Für eine gute und ordentliche Testabdeckung sollten allerdings einige potentielle Fallstricke beachtet werden. Hier einige Beispiele.
Python hat sich als Mittel der Wahl bei Unit Tests weitgehend etabliert. Für eine gute und ordentliche Testabdeckung sollten allerdings einige potentielle Fallstricke beachtet werden. Hier einige Beispiele. (Bild: Clipdealer)

Unit Tests sind wohl die bekannteste Teststufe, die von Entwicklern vor der Integration in die Versionsverwaltung ausgeführt wird. Zunehmend wird dazu die Skriptsprache Python verwendet. Der folgende Beitrag zeigt, wie typische Fallstricke beim Testdesign mit Python umgangen werden können.

Tests sind ein wichtiger Bestandteil in der modernen Softwareentwicklung. Die Vorteile, die man aus einer guten Testabdeckung ziehen kann, sind:

  • Wachsendes Vertrauen in das Produkt
  • Reproduzierbarkeit
  • Aussagekräftige Statistiken
  • Schnellere Refactoring-Zyklen
  • Einfache Einbindung in ein Continuous Integration-System

Alle genannten Punkte gelten selbstverständlich für jede Programmiersprache. Ist die angewandte Programmiersprache statisch typisiert und kompiliert, so schließt der Compiler in der Regel bereits eine große Klasse von Fehlern aus.

Python ist eine sehr populäre Sprache und findet in allen Branchen Anwendung. Python wird attestiert, einfach zu erlernen und gut lesbar zu sein. Der Hauptgrund für Pythons Beliebtheit birgt aber auch Risiken: Python ist eine dynamisch typisierte Interpretersprache. Das heißt: Abgesehen von Syntaxfehlern wird alles zur Laufzeit abgehandelt. Üblicherweise kommt Python in kleinen bis mittelgroßen Projekten zum Einsatz, oder aber begleitend im Projekt-Tooling. Die Schnelligkeit und Leichtigkeit, mit Python zum Ziel zu kommen verleitet dazu, gewissen Mustern zu folgen, die das spätere Testen erheblich erschweren. Es ist sehr üblich, dass erst ab einem gewissen Reifegrad des Projekts die Notwendigkeit von Tests erkannt wird. Zu diesem Zeitpunkt stellt der bestehende Code dann oft eine unerwartet große Hürde dar.

Der Punkt, der fast immer zu wenig Beachtung findet, ist das "Design for Testability". Damit ist - zumindest im Kontext des hier behandelten Unit Tests - der Entwurf von Klassen und Funktionen mit dem Ziel reduzierten Aufwands bei der Testerstellung sowie geringere Fehleranfälligkeit und bessere Lesbarkeit der Tests gemeint. Im vorliegenden Artikel soll das Problem zustandsüberladener Klassenimplementierungen erörtert werden und Lösungen zu ihrer Vermeidung gezeigt werden.

Typische Szenarien für Unit Tests mit Python

Die einfache Zusammenfassung der folgenden Argumentation lautet: Je öfter self im Code zu finden ist, desto schwieriger wird das Testen.

In Pythons Klassenmodell stellt self die Referenz auf die aktuelle Instanz der Klasse dar. Dies ist vergleichbar mit dem Konzept von this in C++. Die Nutzung oder bloße Anwesenheit von self zieht aber immer eine Kopplung an den Zustand der Instanz mit sich. Als einfache Daumenregel gilt: Mehr Zustand bedeutet auch mehr Totlast beim Testen.

Der Grund dafür ist einfach: Zustand kann nicht ignoriert werden. Er findet sich implizit überall, sobald eine Klasse instanziiert wird. Das folgende Codebeispiel zeigt eine zustandsbehaftete Klassendefinition.

1  class Example:
2      def __init__(self, x):
3          self.x = x
4
5      # ...
6
7  ex = Example(5)
8  print(ex.x)
9  # 5
10 ex.x = 6
11 print(ex.x)
12 # 6

Jede Instanz der Klasse Example hat ihre eigene Kopie der Variable x. Im Programmverlauf kann sich der Wert der Variable mehrfach ändern, was eine Zustandsänderung der entsprechenden Instanz mit sich zieht. Der Zustand von ex in Zeile 8 ist nicht identisch mit dem Zustand in Zeile 11.

Im obigen Beispiel ist ex.x zunächst gleich 5. Dies gehört zum impliziten Zustand des Objekts. Überall dort, wo die Referenz auf ex existiert, kann dieser Zustand potentiell verändert werden. In der Regel kann man nicht wissen, ob ein vorhergehender Funktionsaufruf den Zustand des Objekts nicht verändert hat.

Das Dilemma äußert sich wie folgt: Was für das alltägliche Programmieren eine Erleichterung darstellt, weil Änderungen beiläufig erledigt werden können, rächt sich später beim Testen. Sehr oft werden Klassenattribute verwendet, um Methoden mit weniger expliziten Argumenten zu erzielen:

Probleme, die sich aus sich ändernden Objekten ergeben

Warum stellt das ein Problem dar? Es wird immer dann problematisch, wenn eine Klasse komplexe Objekte enthält, typischerweise andere Klassen. Unit Tests basieren auf dem Gedanken, einzelne Funktionen oder Funktionsblöcke aus der Gesamtanwendung freizulegen und separat zu testen. Um dieses Ziel zu erreichen, muss man eine gesicherte Umgebung für die Testeinheit anlegen. Gesichert bedeutet in diesem Kontext eine genaue Kenntnis beziehungsweise Vorbereitung des Ausgangszustandes vor dem Test in dem Umfang, wie der Zustand den Test beeinflusst. Dies beinhaltet eine hinreichend funktionsfähige Bereitstellung des Zustands und von Abhängigkeiten. Je komplexer die beteiligten Klassen und je größer die impliziten Abhängigkeiten, desto nichttrivialer wird die Umsetzung einer solchen Bereitstellung.

Ergänzendes zum Thema
 
Fakes, Stubs & Mocks

Hier einige Beispielhafte Implementierungen einer Klasse:

1  class Example_Version1:
2      def __init__(self):
3          self.connected = False
4      # ...
5
6      def react(self, event):
7          if self.connected:
8              #...
9
10     def onEvent(self, event):
11         #...
12         self.react(event)

Der Code in diesem Beispiel ist sehr gängige Praxis in der kommerziellen Pythonprogrammierung und die meisten Programmierer würden ihn als intuitiv und leserlich empfinden. Eine alternative Implementierung könnte dagegen das connected-Flag als Funktionsparamter explizit übergeben. Während der erste Ansatz stark objektorientiert (zustandsbehaftet) ist, versucht der zweite Ansatz funktional zu bleiben. Objektorientiertes Programmieren und funktionales Programmieren sind zwei unterschiedliche Strömungen in der Softwareentwicklung.

Richtiges Verhältnis zwischen funktionaler und objektorientierter Programmierung

Im Alltag gilt es, das richtige Verhältnis zwischen den Maximen der funktionalen und der objektorientierten Programmierung zu finden und in der Praxis wird es immer zu einem Kompromiss kommen. Fakt ist: Ohne Zustand geht es nicht. Jede Anwendung hat bestimmte Daten, die über mehrere Funktionsaufrufe hinweg Bestand haben müssen. Die Persistenz der Daten über die Funktionsaufrufe sollte aber auf ein Minimum reduziert werden. Im Kontext dieses Beitrags soll FP Funktionen bedeuten, die nur ihre expliziten Funktionsparameter zur Berechnung heranziehen und Seiteneffekte (Input/Output) auf ein Minimum reduzieren, im Bestfall vermeiden.

Ergänzendes zum Thema
 
FP vs. OOP

1  class Device:
2      def __init__(self, network, separator, id):
3          self.network = network
4          self.message_separator = separator
5          self.id = id
6          
7          self.message_buffer = bytes()
8          self.requests = []
9          self.connected = False
10
11         self._request_map = {
12             'request_X': 42
13             # ...
14         }
15         self.setup()
16
17 def setup(self):
18     self.my_addr = self.iface.get_next_free_address()
19     if self.is_valid_addr():
20         self.connected = True
21
22 def data_received(self, data):
23     self.message_buffer += data
24     self.parse_data()
25     self.respond()
26
27 def respond(self):
28     for resp in self.requests:
29     resp = self.lookup_response(req)
30     self.network.send(resp)
31     self.requests = []
32
33 def parse_data(self):
34     for msg in self.message_buffer.split(self.message_separator):
35         # ...
36         self.requests.append(request)
37     # Es ist möglich das der letzte Teil des Nachrichtenpuffers eine
38     # unvollständige Nachricht enthält, diese sollte im Puffer
39     # behalten werden...

40      self.message_buffer = uncomplete_message
41 def lookup_response(self, request):
42      if request in self._request_map:
43          return self._request_map[request]
44      return None
45
46 def is_valid_addr(self):
47      #...
48      return is_valid

Das Klassenbeispiel in Beispiel 3 stellt das Skelett einer einfachen Klasse mit Netzwerkanbindung dar. Die Klasse empfängt Daten aus dem Netzwerk über die Callback-Funktion data_received als Bytes. Anschließend müssen die Daten in einzelne Komponenten zerlegt und interpretiert werden. Zu jeder Nachricht wird eine Antwort generiert und anschließend über das Netzwerk verschickt.

Der Aufbau der Klasse im dritten Codebeispiel folgt gängiger Praxis. Lookup-Hashtabellen, Statusvariablen und beteiligte Klassen werden über self referenziert. Diese Daten sind damit Teil der Klasse selbst und je nach deren aktuellen Werten wird sich eine Instanz dieser Klasse anders verhalten.

Aufsetzen eines geeigneten Unit Tests

Unser Ziel sei es, einen Unit Test für die Methode parse_data zu schreiben. Weil diese Methode den internen Nachrichtenpuffer der Klasse verwendet, bedeutet das, wir müssen eine Instanz dieser Klasse erzeugen. Das bedeutet aber auch, dass der Konstruktor der Klasse aufgerufen wird. Er erwartet unter anderem ein Objekt einer Netzwerkklasse (Abb. 3, Zeile 2 und 3). Dieses Objekt wird an mehreren Stellen verwendet. Folglich reicht ein naiver Mock nicht aus, um genügend Funktionalität zur Verfügung zu stellen, so dass kein Unterschied zum Original erkennbar wird. Obwohl wir nur eine Methode der Klasse testen möchten, zwingt uns die implizite Zustandsverknüpfung dazu, andere Klassen in nicht-trivialer Weise zu mocken.

Abhilfe

Sehen wir uns jetzt die gleiche Klasse nochmals an, aber diesmal wurden die impliziten Abhängigkeiten entschärft.

class Device:
    _request_map = {
        'request_X': 42
        # ...
    } # Teil der Klasse, kein self


    def __init__(self, network, separator, id):
        self.network = network
        self.message_separator = separator
        self.id = id

        self.message_buffer = bytes()
        # self.requests wird nicht mehr benötigt
        self.connected = False

        self.setup()

    def setup(self):
        self.my_addr = self.network.get_next_free_address()
        if self.is_valid_addr(self.my_addr):
           self.connected = True

    def data_received(self, data):
        self.message_buffer += data
        requests, uncomplete = self.parse_data(self.message_separator, self.message_buffer)
        self.respond(self.network, requests)
        self.message_buffer = uncomplete

    @classmethod
    def respond(cls, network, requests):
        for req in requests:
            resp = cls.lookup_response(req)
            network.send(resp)

    @classmethod
    def parse_data(cls, message_separator, message_buffer):
        requests = []
        for msg in message_buffer.split(message_separator):
            # ...
             requests.append(request)
        return requests, uncomplete_message

    @classmethod
    def lookup_response(cls, request):
         if request in cls._request_map:
            return cls._request_map[request]
        return None

    @staticmethod
    def is_valid_addr(addr):
        #...
        return is_valid

In der im obigen Beispiel gezeigten Implementierung wurde versucht, Logik und Funktionalität auf die Klasse selbst zu verlagern, nicht auf konkrete Instanzen. Die Unterschiede im Vergleich zu der Implementierung in Beispiel 3 sind in fett hervorgehoben. Der große Vorteil besteht darin, dass parse_data(),lookup_response(), is_valid_addr() und respond() vollständig getestet werden können, ohne jemals eine Instanz der Klasse Device erzeugen zu müssen. Bis auf respond() ist es auch nicht notwendig, einen Stub der Netzwerkklasse zur Verfügung zu stellen. Ein Stub der Netzwerkklasse für einen Test von respond()benötigt lediglich ein send() und ist damit erheblich einfacher bereitzustellen als ein Stub, der für die gesamte Klasse genügt.

Ein Unit Test könnte wie folgt aussehen:

from Somewhere import Device

def test_parse_data():
    sep = ";"
    inputs = [...]
    expected_outputs = [...]
    for inp, expected in zip(inputs, expected_outputs):
        output = Device.parse_data(sep, inp)
        assert output == expected

Beispiel 5 hier zeigt eine mögliche Implementierung eines Testfalls für parse_data() aus der Implementierung in Beispiel 4. Der Testfall erstellt eine Liste von Eingabewerten und eine Liste der erwarteten Ausgaben. Anschließend wird über diese Spezifikationen iteriert und sichergestellt, dass für jede Eingabe die erwartete Ausgabe erfolgt. Die Funktion zip() wird genutzt, um jeden Input mit dem jeweils erwarteten Output zu verknüpfen.

Einfacher kann ein Unit Test nicht aussehen. In diesem Test wird kein Objekt der Klasse Device erzeugt. Die Methode der Klasse kann fast wie eine normale Funktion benutzt werden, sie muss nur über das Objekt Device angesprochen werden. In dieser Situation verhält sich die Klasse Device wie ein namespace in C++. Vergleichen wir dies mit einem Unit Test für die erste Implementierung:

from Somewhere import Device
from Unit Test.mock import Mock

class NetworkMock(Mock):
    def get_next_free_address(self):
        # ...
    def register(self, id):
        # ...
    def send(self, data):
         # ...

def test_parse_data():
    sep = ";"
    inputs = [...]
    expected_outputs = [...]
    network = NetworkMock()
    device = Device(network, sep, 42)
    for inp, expected in zip(inputs, expected_outputs):
        device.message_buffer = inp
        device.parse_data()
        output = device.requests
        assert output == expected
        device.message_buffer = []
        device.requests = []

Es ist auffällig, wie viel Aufwand notwendig ist, bis wir die zu testende Methode soweit freigestellt haben, dass wir sie testen können. Ich möchte besonders die Notwendigkeit hervorheben, am Ende jeder Iteration der for-Schleife die Daten wieder zurückzusetzen. Nachdem die Funktion diese internen Variablen benutzt, diese aber außerhalb des echten Anwendungsfalls nicht geleert werden, würden sich die Daten anhäufen. Das ist nicht nur lästig, sondern auch ein potentielles Risiko für die Korrektheit der Testimplementierung.

Man kann einwenden, dass setup() und data_received() in der zweiten Implementierung immer noch die gleichen Probleme aufweisen. Das ist korrekt, aber ein Kompromiss der in der Regel eingegangen werden muss. Im Falle einer unvollständigen Nachricht muss diese bis zum Eintreffen neuer Bytes erhalten bleiben. Dies kann nur geschehen indem diese Daten bis zum nächsten Aufruf von data_received im Speicher bleiben. Die Daten im Zustand der Klasse abzulegen ist der einzige Weg. Die data_received Methode muss daher zustandsbehaftet bleiben. Bei genauerem Hinsehen fällt jedoch auf, das weder setup noch data_received substanzielle eigene Logik implementieren. In diesen Funktionen wird über bereits vorhandene Ergebnisse iteriert beziehungsweise Funktionen der Netzwerkklasse aufgerufen. Mit den Unit Tests haben wir abgesichert, dass die Ergebnisse, über die iteriert wird, korrekt sind. Die Tests der Klasse Device sollten nicht dazu missbraucht werden, auch die Netzwerkklasse abzutesten. An dieser Stelle sollte dafür gesorgt werden, dass für diese Klasse ein eigener Unit Test existiert.

Unter diesen Umständen wäre es vertretbar keinen Test für setup und data_received zu implementieren. Eine solche Entscheidung ist aber stark fallabhängig.

Unit Tests mit Python können mitunter ein Umdenken erfordern

Die gesammelten Erkenntnisse lassen sich wie folgt zusammenfassen:

  • self so wenig wie möglich verwenden,
  • @classmethod und @staticmethod dagegen so häufig wie möglich.
  • Möglichst viele Attribute als Klassenattribute anlegen.
  • Explizite Argumentübergaben und Funktionsrückgaben sind den impliziten Varianten vorzuziehen.
  • Jede eigenständige logische Einheit der Klasse als eigene Funktion anlegen.
  • Input/Output sollte in so wenigen Funktionen wie möglich verwendet werden

Manche dieser genannten Punkte erfordern ein Umdenken beziehungsweise einen Stilbruch zu bestehenden Gepflogenheiten. Zum Beispiel sollten Klassenattribute über einen expliziten Funktionsaufruf einer classmethod oder staticmethod neue Werte zugewiesen werden anstatt diesen inmitten von anderer Logik Zwischenergebnisse zuzuweisen. Die Investition in diese Maßnahmen zahlt sich aber unmittelbar dadurch aus, dass der Aufwand und die Wartbarkeit für Tests erheblich reduziert werden.

Beispiel

self.x = get_new_value(a, b, c)

ist besser als


a = y[-1]
b = self.z[0]
self.x = y[a:b]
for i in y:
….

Der Autor

Der Autor: Tobias Pleyer, MixedMode.
Der Autor: Tobias Pleyer, MixedMode. (Bild: MixedMode GmbH)

* Tobias Pleyer ist Master of Science Physik. Er hat Erfahrung in den Branchen Automotive und Medizin als State Event Machine Entwickler, Projectengineer, Continuous Integration Engineer und Testingenieur gesammelt.

Abhängigkeiten selbst gestalten: Mit Dependency Injection zu flexiblem Software-Design

Abhängigkeiten selbst gestalten: Mit Dependency Injection zu flexiblem Software-Design

29.08.18 - Um ein funktionierendes und modulares Softwaresystem zu erhalten, sind Abhängigkeiten im Softwaredesign leider bis zu einem gewissen Grad unvermeidlich. Daher sollten sie vom Entwickler von vorneherein gezielt angelegt werden, so dass sie möglichst wenig stören. Das Entwurfsmuster Dependency Injection (DI) hilft hierbei. lesen

Mit Pyparsing eine eigene Skriptsprache zur Embedded-Entwicklung definieren

Mit Pyparsing eine eigene Skriptsprache zur Embedded-Entwicklung definieren

14.08.18 - Python ist auch in der Embedded-Entwicklung zur Generierung praktischer Scripts beliebt. Mit Pyparsing besteht zudem die Möglichkeit, mit wenig Aufwand eine auf die eigenen Bedürfnisse zugeschnittene Skriptsprache zu definieren, die innerhalb des Python-Kontextes läuft. lesen

Die zwei großen Fallen bei der Code Coverage

Die zwei großen Fallen bei der Code Coverage

13.06.18 - Manche meinen, dass nur 100%-ige Code Coverage auch für gute Softwarequalität stehen kann. Andere haben ihre Codeabdeckung dagegen gar nicht im Blick. Beides kann aber letztendlich für die Softwarequalität und -Sicherheit fatal sein. lesen

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45478099 / Test & Qualität)