Pochodząc z analityki i nauki o danych, pisanie testów postrzegałem jako coś bolesnego. Wiedziałem, że to ważne, ale nigdy nie wiedziałem od czego zacząć i zawsze zwlekałem do końca projektu. Co jest bardziej nudne niż testowanie fragmentu kodu, który już działa?

Ostatnio zacząłem patrzeć na rzeczy z innej strony. Odkryłem Test-Driven Development: pisz swoje testy, zanim zaczniesz kodować funkcjonalną część kodu. To najlepsza praktyka inżynierii oprogramowania, która zasługuje na częstsze stosowanie w projektach data science.

Co to jest programowanie sterowane testami (TDD)?

Prostym sposobem na umieszczenie tego jest użycie struktury Red/Green/Refactor . Za każdym razem, gdy chcesz dodać funkcjonalność do kodu, możesz wykonać trzyetapowy cykl:

1. czerwony . Utwórz test, który zakończy się niepowodzeniem. tj. napisz potrzeby funkcjonalne swojego kodu
2. Zielony . Napisz kod produkcyjny, który sprawia, że ​​test przechodzi pomyślnie. czyli spełniać potrzeby funkcjonalne kodu
3. Refaktoryzacja. Posprzątaj bałagan, który właśnie zrobiłeś. tj. wyczyść swój kod bez zmiany funkcjonalności

Zilustrujmy to przykładem z życia wziętym. W ramach etapu przetwarzania końcowego dla projektu Rozpoznawanie jednostek nazwanych chcemy zbudować funkcję przetwarzania w celu wyodrębnienia jednostki czasu trwania (dzień/tydzień/miesiąc/..) i wartości czasu trwania w tekście.

1. Napiszmy test jednostkowy, który spełnia potrzeby funkcjonalne i pustą funkcję.

2. Piszemy kod, który zdaje egzamin.

Test jest ZIELONY Hurra!! Czekaj.. czy na pewno jest SUCHY, SOLIDNY, pep8??

3. Refaktoryzujemy funkcję, aby zapewnić najlepsze praktyki kodowania.

Tutaj dodaliśmy adnotacje typu, stworzyliśmy ogólną funkcję konwertującą numer litery na liczbę zmiennoprzecinkową (również z własnym testem jednostkowym) i zmieniliśmy sposób wypełniania słownika.

Gdzie możemy zastosować Test-Driven Development w Data Science?

Programowanie oparte na testach nie jest istotne na każdym etapie projektu nauki o danych. Na przykład nie warto tego robić podczas eksploracji danych lub modeli , gdy nie jesteś pewien, czego szukasz: pisanie testów bez znajomości oczekiwanych wyników jest prawdopodobnie przesadą.

Staje się bardzo przydatne, gdy trzeba zbudować solidne potoki produkcyjne .

W tym kontekście musimy wdrożyć kilka rodzajów testów:

• Testy jednostkowe: test dla każdego fragmentu kodu projektu
• Testy modelu : upewnij się, że model ma dobrą wydajność i zachowuje się poprawnie
• Testy integracyjne : upewnienie się, że istnieje dobre powiązanie między każdym fragmentem kodu

W przypadku testów modelowych należy go używać ostrożnie. Gdy mamy do czynienia z modelami predykcyjnymi, mamy do czynienia z niepewnością . Rzeczywiście, wiele algorytmów uczenia maszynowego jest z natury losowych — wiele przebiegów wykorzystujących te same dane wejściowe może za każdym razem dawać nieco inne wyniki. Może to prowadzić do niestabilnych testów : testu, który czasami przechodzi pomyślnie, a czasami kończy się niepowodzeniem, pomimo braku zmian w kodzie lub samym teście. Jeśli jesteśmy zbyt dokładni w przypadku przypadków testowych podczas pierwszego programowania opartego na testach, jest wysoce prawdopodobne, że niektóre testy zepsują się w następnej iteracji. Nowy model może zachowywać się inaczej w niektórych przypadkach, jednocześnie osiągając lepsze wyniki globalnie. Dlatego lepiej jest uwzględniać w testach modelowych tylko podstawowe przypadki, które są niezbędne w projekcie.

Wreszcie w przypadku testów integracyjnych dobrze sprawdza się w przypadku fragmentów kodu, które nie zawierają przewidywań modelu. Jeśli obejmuje przewidywanie modelu, lepiej jest przetestować format danych wyjściowych niż rzeczywisty wynik.

Dobrą praktyką jest włączenie tych testów do CI/CD twojego projektu. Dlatego za każdym razem, gdy przedstawiana jest propozycja nowej funkcjonalności, zapewnia się, że żadna inna funkcjonalność się nie zepsuje.

Dlaczego zmienia zasady gry?

Przyjęcie programowania opartego na testach naprawdę zmienia sposób organizacji sesji kodowania i ma mnóstwo zalet:

• Błyskawicznie weryfikuje specyfikacje biznesowe i techniczne . Jest to również świetna dokumentacja dla analityka danych, który odkrywa projekt i musi zrozumieć, jak działa projekt.
• Daje zaufanie do kodu . Każdy przypadek użycia jest objęty testem, a Ty lub Twoi współpracownicy możecie dodawać dodatkowe funkcjonalności bez obawy, że zepsujecie coś, co już zostało zrobione.
• Oszczędność czasu . Można to postrzegać jako coś, co spowalnia rozwój. Ale tak nie jest, zmusza cię to do wcześniejszego przemyślenia potrzeb funkcjonalnych i przewidywania przypadków brzegowych. Uwierz mi, na koniec dnia oszczędza to dużo czasu na debugowanie i iterację.
• To nawet sprawia , że ​​rozwój jest przyjemniejszy ! Rozbija kod na małe wyzwania związane z rozwiązywaniem problemów. I idealnie pasuje do kodowania równorzędnego.