Testing

Ein Test für place_order braucht ein Payment-Gateway, einen SMS-Client und einen Steuerrechner. Setzen Sie die echten Objekte ein: Jeder Testlauf belastet dann eine Karte und verschickt eine SMS an eine echte Telefonnummer. Ein Unit-Test soll in Millisekunden laufen, ohne Netzwerkzugriff — also müssen alle drei durch etwas anderes ersetzt werden. Dieses „etwas andere“ gibt es in fünf Varianten, die jeweils ein anderes Problem lösen. Wer sie für austauschbar hält, erlebt im Code-Review immer wieder dieselbe Debatte: „dann mock das doch einfach“. ...

Ein Test, der nach dem Code geschrieben wird, prüft meist, was der Code tut, nicht, was er tun sollte. Testgetriebene Entwicklung (TDD) behebt das, indem sie die Reihenfolge umdreht: Sie schreiben den Test, sehen ihn fehlschlagen und schreiben dann den kleinsten Code, der ihn bestehen lässt. Weil der Test existiert, bevor der Code existiert, den er prüft, kann er nicht stillschweigend bestätigen, was der Code gerade zufällig zurückgibt. Kent Beck hat diese Schleife in seinem Buch Test-Driven Development: By Example von 2002 als red, green, refactor formalisiert. Der Name ist geblieben. ...

Eine Funktion kann 100 % Unit-Test-Abdeckung haben, und die Seite, die sie aufruft, kann in Produktion trotzdem einen 500er zurückgeben. Das ist kein Widerspruch. Unit-, Integrations- und End-to-End-Tests prüfen unterschiedliche Dinge, und eine Testsuite, die bei einer Ebene stark und bei einer anderen schwach ist, hat ein bestimmtes, vorhersehbares Loch. Was Unit-, Integrations- und End-to-End-Tests jeweils prüfen Nehmen Sie eine Registrierungsfunktion: Eine Funktion validiert die Eingabe, schreibt eine Zeile in eine Datenbank und verschickt eine Willkommens-E-Mail. Drei Tests können das abdecken, und jeder beantwortet eine andere Frage. ...