Biurkowa tablica pseudo kanbanowa

Hej!

Ostatnio doszedłem do wniosku, że fajnie by było postęp niektórych moich przedsięwzięć śledzić na zasadzie tablicy scrumowej, tak jak dzieje się to u mnie w pracy. 

Stwierdziłem, że postawię na tablicę wirtualną zamiast fizycznej, z racji jej większej "mobilności". Nie potrzebowałem żadnych specjalnych możliwości - jedynie możliwość dodawania "backlog itemów", przypisywania do nich zadań i przeciągania ich po tablicy. Szukałem długo odpowiedniej aplikacji, w pewnym momencie nawet miałem ochotę napisać własną, kiedy zdałem sobie sprawę, że za bardzo kombinuję - jak to zwykle bywa, najlepsze są te najprostsze rozwiązania. Ściągnąłem zatem aplikację XPad i korzystając ze zwykłych żółtych karteczek skleciłem coś takiego:

Test Driven... Design?

Ostatnio miałem kilka dyskusji na temat testów jednostkowych oraz Test Driven Development.

Postaram się omówić główne punkty mojej argumentacji za stosowaniem testów jednostkowych oraz metody TDD, którą wolę tłumaczyć jako Test Driven Design.

1. "Nie ma dowodów, że w ten sposób znajduje się więcej błędów"

TDD nie służy do znajdowania błędów (przynajmniej nie taki jest jego główny cel). Jego przeznaczeniem jest projektowanie aplikacji, tzn. pisze się najpierw test, służący specyfikacji fragmentu funkcjonalności, który mamy zaimplementować. W tym sensie zestawy testowe są wykonywalnym zamiennikiem dla dokumentów tzw. Low Level Design, gdzie jest opis słowno - muzyczny i diagramy UMLowe.

2. "TDD cierpi na tzw. "syndrom ojcostwa" - jeśli ktoś pisze testy, to robi te same założenia, co pisząc kod. Normalniejsze podejście jest takie, że testy pisze jedna osoba, a kod druga".

TDD nie służy do znajdowania luk i błędów w naszym rozumieniu wymagań. Od tego są inne metody testowania. TDD służy jedynie do upewnienia się, że kod robi to, co chcemy, żeby robił (bez względu, czy jest to zgodne z wymaganiami, czy nie). Owszem, fakt że piszemy testy tylko w oparciu o wymagania pomaga nam nie czynić założeń oraz druga osoba może potem przejrzeć scenariusze testowe i zweryfikować ich poprawność - w tym sensie weryfikuje nasz projekt.

4. "TDD to strata czasu - można przecież od razu pisać kod".

a) Jak wspomniałem, można traktować zestawy testów jednostkowych jako wykonywalne dokumenty LLD. Warto zadać sobie pytanie, czy łatwiejszy i mniej czasochłonny w pisaniu i utrzymywaniu jest taki dokument (który czasami potrafi mieć nawet 60 stron A4), czy zestaw testów, które dodatkowo weryfikują kod.

b) Skłaniam się do traktowania również procesu puszczenia testów jednostkowych jako elementu kompilacji. Kompilacja kodu np. w C++ również zajmuje sporo czasu, natomiast wielu z nas nie chciałoby oddawać gwarancji uzyskanych przez sam fakt, że kompilujemy nasz kod (zazwyczaj jest to sprawdzanie typów, statyczna analiza kodu itp.). Bruce Eckel zauważył nawet, że w przypadku języków interpretowanych, takich jak Python, posiadając zestaw testów jednostkowych pokrywających znaczny obszar kodu, wcale nie tęskni za kompilacją kodu, bo jeśli wszystkie testy przechodzą, to znaczy, że nie ma w nim błędów, które mógłby wyłapać kompilator.

c) Testy jednostkowe pelnią rolę dokumentacji i listy kontrolnej. W tym pierwszym znaczeniu dobrze dokumentują kod i gwarancje, które muszą być przezeń spełnione. W tym drugim - dobrze pokazują w trakcie kodowania, co jest już zaimplementowane, a co oczekuje na implementację. Stosując się do zasady pisania testów najpierw, wiemy że nienapisany test = niezaimplementowana funkcjonalność. Dzięki temu łatwiej sprawdzić, które wymagania mamy pokryte, a które nie.

5. "Testy jednostkowe utrudniają zmiany w kodzie, bo w razie czego trzeba je przerabiać".

Z mojego doświadczenia wynika, że testy jednostkowe ułatwiają zmianę, bo duże pokrycie funkcjonalności testami daje nam dużą pewność, że nic nie popsujemy. I znowu, jeśli uznamy, że nienapisany test = niezaimplementowana funkcjonalność, to wiemy, że jeśli cały zestaw testów przejdzie po naszych zmianach, to jesteśmy bezpieczni.

"A language that doesn’t affect the way you think about programming is not worth knowing"

To zdanie znalazłem na jednym z blogów. Jest to szczera prawda i jednocześnie jeden z powodów, dla których ostatnio jakoś specjalnie nie ciągnęło mnie do Javy i C# - dużo bardziej interesujące były dla mnie języki, które proponują swoje własne rozwiązania różnych problemów, a nie tylko kopie istniejących tylko w lekko wzbogaconej/zubożonej wersji. Dlatego też języki, na które w wolnej chwili zamierzam poświęcić więcej czasu to Eiffel, Lisp, Erlang i języki dynamiczne. Swoją drogą zastanawiają mnie te wszystkie wzorce projektowe, które są tak modne w tych najbardziej modnych językach - kiedyś wyczytałem taką myśl, że ilość wzorców projektowych jest wprost proporcjonalna do stopnia upośledzenia języka, bo wzorce te mają często za zadanie symulować mechanizmy, które w innych, bardziej elastycznych językach, są dostępne od ręki. Trudno mi się z tym, przynajmniej częściowo, nie zgodzić.