Pisać testy jednostkowe do wszystkiego? Celować w 100% unit-test-code-coverage? Stosować TDD dla każdego rodzaju kodu? Na te pytania bardzo łatwo znaleźć w internecie odpowiedź i brzmi ona: TAK. Niestety nie jest to odpowiedź prawidłowa. Czasem lepiej testu nie napisać, niż go napisać. Czasem lepiej test skasować, niż go po raz dziesiąty poprawiać po zmianie w kodzie. Prawdziwą sztuką jest takie pisanie testów, aby czas spędzony na ich tworzeniu zwrócił się w dalszym życiu systemu. Sztukę tą szlifuje się przez lata praktyki i jest to zdecydowanie bardzo trudne zadanie. Ja cały czas jestem “w drodze”, tzn. pomimo ładnych kilku lat stosowania różnych podejść do testowania, różnych frameworków, przeczytaniu tysięcy stron książek, artykułów i blogów na ten temat nadal mam wrażenie, że więcej nie wiem niż wiem. No cóż… życie.
Bardzo ważnym krokiem w “testowej edukacji” jest uświadomienie sobie, że:
A suite of good unit tests is immensely valuable (…) However, a suite of bad unit tests is immensely painful
Nie każdy kod zasługuje na test. Nie każdy test zasługuje na utrzymywanie. Wiele testów jest po prostu do niczego.
Źródło: Steve Sanderson, “Writing Great Unit Tests: Best and Worst Practices” (btw, polecam lekturę wszystkich postów Steve’a z kategorii Testing, a na bloga zwróciłem uwagę dzięki twittowi by @rafek, dzięki!)
