Początkowo temat miał brzmieć „TDD – dlaczego u mnie nie działał” ale stwierdziłem, że nie chcę się rozpisywać o TDD (Test Driven Development) a głównie o pisaniu testów.
O TDD zrobiło się głośno już jakiś czas temu. Samo słowo okrzepło podobnie jak Agile i podobnie zarabia na siebie licznymi szkoleniami w tym temacie.
Nie zamierzam pisać na temat TDD samego w sobie. Jest mnóstwo materiałów w sieci zarówno anglojęzycznych jak i polskojęzycznych. Ze swej strony polecam nagrania z konferencji geecon z Poznania z 2015 r. udostępnione na vimeo. TO na czym się skupie to dlaczego JA nie byłem w stanie wdrożyć TDD u siebie. Nie byłem w stanie nawet wdrożyć systematycznego pisania testów.
powyższa ilustracja pochodzi z prezentacji którą wygłosili LAFK i KTOSO.
Więc ja znajdowałem się w połowie drogi między TESTAMI MANUALNYMI a PO i nie byłem w stanie zmienić swoich nawyków aby pójść dalej. Nikt tego nie wymagał ode mnie co czyniło sprawę jeszcze trudniejszą. Za każdym razem gdy stwierdzałem, że jakiś fragment kodu pasowałoby by przetestować to siadałem i pokrywałem istniejący kod. Zdarzało się, że znajdowałem jakieś drobne błędy lub niespójności, była to też okazja do refaktoryzacji, lecz zazwyczaj pisałem testy pod moje komponenty, a nie na odwrót.
Kod znacznie się zmienia jeśli podstawowe testy jednostkowe piszesz jeszcze przed faktyczną funkcjonalnością, ale jak zmienić nawyki, by tworzyć w ten sposób?
Moja propozycja wygląda następująco.
- Najpierw tworzysz klasę która będzie rozwiązywać twój problem. Na razie Czystą bez implementacji, chodzi tylko o to aby powstał odpowiednio nazwany plik.
- Będąc w tym pliku pierwsze co robimy to tworzymy dla niego nowy test. Jeśli używasz InteliJ Idea to jest skrót klawiszowy CTRL + SHIFT + T który utworzy nowy plik testu do kodu nad którym pracujemy. Skrót ten pozawala przejść do już istniejącego testu, a także powrócić z testu bezpośrednio do kodu naszej aplikacji.
- odpalamy test w konsoli sbt. Próbowałem używać InteliJ’a do odpalania testów, ale to było zbyt uciążliwe. Możemy odpalić wszystkie testy test tylko po co? jest to raczej niepraktyczne szczególnie jeśli jest ich sporo. Poza tym pracujesz obecnie tylko nad jednym zagadnieniem i zazwyczaj jedyne czego chcesz to odpalić dokładnie te testy które przed chwilą napisałeś. Sbt posiada narzędzie do tego testOnly *MyTest. Uruchomi ona testy pasujące do wzorca *MyTest. Aby test wykonywał się za każdym razem gdy zmieni się coś w projekcie dodaj tyldę przed komendą ~testOnly *MyTest.
- Piszemy pierwszy test który ma za zadanie tylko stworzyć instancje naszej klasy (i tu istotna informacja. Nie używamy konstruktora który już istnieje, ale piszemy to w taki sposób jakbyśmy chcieli aby on wyglądał. Kod się nie skompiluje, ale będzie to dla nas informacja, że zaplanowaliśmy taki konstruktor/metodę bo wyobraziliśmy sobie jej użycie, a zatem zakładamy że takiego konstruktora będziemy potrzebować.
- Dopisujemy kod w naszej klasie którą testujemy aby wszystko się kompilowało oraz przechodziło nasz test.
- usuwamy wszystko co zbędne i sprzątamy nasz kod. (REFAKTORYZACJA)
- postępujemy podobnie z dalszymi testami.
To na razie tyle. Wiem, że nie odkryłem Ameryki ale to były trzy elementy które pomogły mi znaleźć się po stronie dobra i przekroczyć barierę PO i pójść dalej (a bardzo nie lubię PO).