Spikes – ślepą amunicją ładuj

Główna zasada Test-driven Development mówi by zawsze pisać test najpierw. Jest ona ze wszech miar słuszna i nie podlega dyskusji. Czasem jednak może się zdarzyć sytuacja, że takie postępowanie może być trudne lub wręcz niemożliwe.

Z taką sytuacją moglibyśmy spotkać się na przykład na poligonie gdy podoficer wyda rozkaz.
– Kowalski! Masz mi tu opisać jak tym czołgiem zniszczysz transporter. A potem wskakuj w maszynę i zniszcz wroga.
– Panie chorąży ale ja jestem z marynarki – ja nigdy nawet nie widziałem czołgu!
I cóż ten biedny żołnierz ma zrobić? Przecież on nawet nie ma prawa jazdy na samochód. A tymczasem tutaj są konkretne wymagania: ma rozpisać test i potem go spełnić – wróg ma być rozbity. Ale jak to zrobić? Jak ma opisać sposób w jaki go zniszczy? Jak się tą piekielną machiną w ogóle steruje?

Żołnierz taki, w tej sytuacji, z pewnością nie obraziłby się na możliwość treningu na symulatorze. Nauczy się na nim jazdy. Testuje różne możliwości. W końcu gdy jest już pewny jak to zrobić – podpala symulator, opisuje jak wykona zadanie, wsiada do czołgu i dopiero wtedy ściera wraży obiekt na proch.

Powyższa historyjka obrazowo pokazuje taką sytuację z którą my również możemy spotkać się w życiu codziennym. Może to wystąpić gdy:
– Nie znamy projektu, frameworku lub biblioteki. To jest właśnie naszym czołgiem. Potrzebujemy zdobyć wiedzę jak dana biblioteka działa, by móc opierając się o nią napisać test.
– Nie mamy pojęcia jak rozwiązać konkretny problem. Nie wiemy jaką strukturę powinien mieć kod lub nawet jak mają wyglądać wejściowe/wyjściowe dane. W tym wypadku nie wiemy co test powinien testować a tym samym jak ten test powinien wyglądać.
– Chcemy wypróbować różne możliwości, aby wybrać najlepszą.
– Czy po prostu chcemy zobaczyć jak dany kod może wyglądać. Czy idziemy dobrą drogą? Czy kod spełni nasze oczekiwania?

W tym wypadku potrzebujemy mieć możliwość by najpierw napisać nie test, lecz kod. I… możemy to zrobić. Ale tylko pod jednym, bardzo istotnym warunkiem.

W tej sytuacji możemy użyć tak zwanych “Spikes”. Spikes są niczym innym niż eksperymentem. Kod w tym wypadku może nie posiadać testów. Możemy napisać kod najpierw. Jesteśmy w stanie w ten sposób między innymi sprawdzić pomysł, wybrać rozwiązanie, rozpoznać jak powinien wyglądać test. Wiemy, że symulator czołgu, niezależnie co zrobimy nie zapali się od środka i nie spłoniemy żywcem. Pisząc Spike możemy czuć się wolni i tworzyć kod niemalże bez zasad.  Możemy – gdyż po zakończeniu eksperymentu – wiemy  że musimy usunąć cały kod i napisać go od nowa. Napisać w poprawnym procesie TDD.

Musimy wypalić symulator, wysadzić jego fundamenty i wyrównać teren. Tak by poligon wyglądał identycznie jak wcześniej. W ten sposób zaczynamy z tak samo czystym kodem jak dotychczas. Oczywiście nie zapomnieliśmy nauki płynącej z symulatora, nadal wiemy już jak prowadzić czołg. Teraz tylko musimy pamiętać by to nie wpłynęło na prawidłowy przebieg procesu. Wracamy do TDD i postępujemy prawidłową ścieżką. Piszemy testy najpierw. Nadal rozwiązujemy problem najprostszymi sposobami. Nadal postępujemy małymi krokami. I nadal przenigdy nie piszemy nadmiarowego kodu, kodu nie pokrytego testami, nie wybiegamy myślami w przyszłość. Dzięki temu mamy pewność, że takie eksperymenty nie zaburzą naszego procesu TDD.

Na zakończenie dodam, że warto pamiętać, że możemy oczywiście pisać spike używając TDD i tworząc testy najpierw. Nie ma ku temu żadnych przeciwskazań. Czasami może być to nawet łatwiejsze. Ale wiedząc że cały kod zarówno spike jak i odpowiadających mu testów zostanie usunięty, możemy pozwolić sobie na pewne ustępstwa – których w normalnym procesie nie dopuszczalibyśmy do myśli.

A czy ty używasz spikes? Co sądzisz o tej metodzie?