Da ich aus einem analytischen und datenwissenschaftlichen Hintergrund komme, sah ich das Schreiben von Tests früher als etwas Schmerzhaftes an. Ich wusste, dass es wichtig war, aber ich wusste nie, wo ich anfangen sollte, und zögerte immer bis zum Ende des Projekts. Was ist langweiliger, als einen Code zu testen, der bereits funktioniert?

Vor kurzem habe ich angefangen, die Dinge anders herum zu sehen. Ich habe die testgetriebene Entwicklung entdeckt: Schreiben Sie Ihre Tests, bevor Sie den funktionalen Teil des Codes tatsächlich codieren. Es ist eine bewährte Methode im Software-Engineering, die es verdient, häufiger auf Data-Science-Projekte angewendet zu werden.

Was ist testgetriebene Entwicklung (TDD)?

Eine einfache Möglichkeit, es auszudrücken, ist das Red/Green/Refactor- Framework . Jedes Mal, wenn Sie dem Code Funktionalität hinzufügen möchten, können Sie einem dreistufigen Zyklus folgen:

1. Rot . Erstellen Sie einen Test, der fehlschlägt. dh schreiben Sie die funktionalen Anforderungen Ihres Codes
2. Grün . Schreiben Sie Produktionscode, mit dem der Test bestanden wird. dh die funktionalen Anforderungen des Codes erfüllen
3. Umgestalten. Räumen Sie das Chaos auf, das Sie gerade angerichtet haben. dh bereinigen Sie Ihren Code, ohne die Funktionalität zu ändern

Lassen Sie uns dies anhand eines realen Beispiels veranschaulichen. Als Nachbearbeitungsschritt für ein Named-Entity-Recognition - Projekt wollen wir eine Verarbeitungsfunktion bauen , um die Dauereinheit (Tag/Woche/Monat/..) und den Dauerwert in einem Text zu extrahieren.

1. Lassen Sie uns einen Komponententest schreiben, der die funktionalen Anforderungen und eine leere Funktion erfüllt.

2. Wir schreiben Code, der den Test besteht.

Test ist GRÜN Hurra!! Moment... sind wir sicher, dass es DRY, SOLID, pep8 ist??

3. Wir überarbeiten die Funktion, um Best Practices für die Codierung sicherzustellen.

Hier haben wir Typanmerkungen hinzugefügt, eine generische Funktion erstellt, um die Buchstabennummer in Float umzuwandeln (auch mit einem eigenen Komponententest) und umgestaltet, wie wir das Wörterbuch füllen.

Wo können wir Test-Driven Development in Data Science anwenden?

Test Driven Development ist nicht in jedem Schritt eines Data-Science-Projekts relevant. Zum Beispiel lohnt es sich nicht bei Daten- oder Modellexplorationen , bei denen Sie sich nicht sicher sind, wonach Sie suchen: Tests zu schreiben, ohne die erwartete Ausgabe zu kennen, ist wahrscheinlich zu viel des Guten.

Es ist sehr nützlich, wenn Sie robuste Produktionspipelines aufbauen müssen .

In diesem Zusammenhang müssen wir mehrere Arten von Tests implementieren:

• Unit-Tests: ein Test für jedes Stück Code des Projekts
• Modelltests : Stellen Sie sicher, dass das Modell eine gute Leistung hat und sich korrekt verhält
• Integrationstests : Sicherstellen, dass zwischen den einzelnen Codeteilen eine gute Verknüpfung besteht

Für Modelltests sollte es vorsichtig verwendet werden. Bei Vorhersagemodellen haben wir es mit Unsicherheit zu tun . Tatsächlich sind viele maschinelle Lernalgorithmen von Natur aus zufällig – mehrere Durchläufe mit denselben Eingaben können jedes Mal zu leicht unterschiedlichen Ergebnissen führen. Dies kann zu fehlerhaften Tests führen : ein Test, der manchmal besteht und manchmal fehlschlägt, obwohl keine Änderungen am Code oder am Test selbst vorgenommen wurden. Wenn wir bei einer ersten testgetriebenen Entwicklung zu genau auf die Testfälle eingehen, ist es sehr wahrscheinlich, dass einige Tests bei einer nächsten Iteration fehlschlagen. Ein neues Modell könnte sich in einigen Fällen anders verhalten, während es global besser abschneidet. Daher ist es besser, in Modellversuche nur grundlegende Fälle einzubeziehen, die für das Projekt notwendig sind.

Schließlich gilt es für Integrationstests gut für Codeteile, die keine Modellvorhersagen enthalten. Wenn es eine Modellvorhersage enthält, ist es besser, das Format der Ausgabe als die tatsächliche Ausgabe zu testen.

Es empfiehlt sich, diese Tests in das CI/CD Ihres Projekts aufzunehmen. Daher wird bei jedem Vorschlag einer neuen Funktionalität sichergestellt, dass keine andere Funktionalität unterbrochen wird.

Warum ist es bahnbrechend?

Die Einführung von testgetriebener Entwicklung verändert wirklich die Art und Weise, wie Sie Ihre Codierungssitzungen organisieren, und bietet unzählige Vorteile:

• Es validiert sofort die geschäftlichen und technischen Spezifikationen . Es ist auch eine großartige Dokumentation für einen Datenwissenschaftler, der das Projekt entdeckt und verstehen muss, wie das Projekt funktioniert.
• Es gibt Vertrauen in den Code . Jeder Anwendungsfall wird durch einen Test abgedeckt, und Sie oder Ihre Teamkollegen können zusätzliche Funktionen hinzufügen, ohne befürchten zu müssen, dass etwas bereits Fertiges kaputt geht.
• Es ist zeitsparend . Man kann es als etwas sehen, das die Entwicklung bremst. Aber das ist es nicht, es zwingt Sie, im Voraus über die funktionalen Anforderungen nachzudenken und Grenzfälle zu antizipieren. Glauben Sie mir, am Ende des Tages spart es viel Debugging- und Iterationszeit.
• So macht die Entwicklung sogar noch mehr Spaß ! Es zerlegt den Code in kleine Herausforderungen zur Problemlösung . Und es eignet sich perfekt für die Peer-Codierung.