Wszyscy wiemy, że TDD jest super, tylko dlaczego tak mało z nas stosuje tą metodykę na co dzień? Podczas live codingu postaram się pokazać wam, że życie na fazie może być ciekawe. Oczywiście fazy to - red, green i refactor. Każda faza kojarzy nam się z %integracją%, więc i testy integracyjne się pojawią. Potem postaramy się zostać zaakceptowani przez testy akceptacyjne, a wszystko to będzie sterowane przez TDD. A co z dokumentacją tych wszystkich zdarzeń!? Spokojnie, słyszeliście o Test Driven Documentation?

Testowanie oprogramowania w teorii jest dość prostym zajęciem. Każdy zdefiniowany zestaw akcji generuje pewien zestaw zdefiniowanych i niezmiennych reakcji. Jeżeli reakcja się nie zgadza – zidentyfikowaliśmy błąd (na poziomie aplikacji, błąd w teście lub w specyfikacji).

Istnieje jednak pewien zestaw algorytmów, w którym reakcje potrafią się między sobą różnić pomimo podania tych samych bodźców. W szczególności jest to zauważalne przy samouczących się algorytmach, w których akcje wpływają nie tylko na aktualny wynik, ale i na każdy kolejny, a próba znalezienia logicznego ciągu przyczynowo skutkowego jest często niemożliwa. Mowa tu o algorytmach opartych na Machine Learningu, których wyniki są zmienne w czasie.

Skąd w takim razie możemy wiedzieć, że testowany algorytm działa poprawnie? Jak wybronić swoją aplikację i wytłumaczyć niestandardowe reakcje? A może trzeba takie algorytmy odrzucić? Więcej na samym wykładzie :)