Dlaczego nie piszemy testów – obserwacja

W książkach poświęconych jakości kodu, testowaniu i metodykom zwinnym jako główną przyczynę braku testów wymienia się lenistwo programistów, olewactwo i niechcicę. Pozwolę sobie napisać kilka słów na ten temat.

Od pewnego czasu w związku ze zmianą płatnika ZUS przekazuję swoje obowiązki innym programistom. Przy okazji mam możliwość obserwowania tego jak pracują i w jaki sposób myślą o kodzie oraz projekcie. Niestety przy okazji tych obserwacji weryfikuję moje postrzeganie testów.

//offtopic
Zmiana płatnika ZUS związana jest z tym, że nowy płatnik przyszedł na spotkanie WJUG i zesponsorował nam pizzę. Zatem jeżeli potrzebujesz pracowników to warto pojawić się na spotkaniu JUGa jako sponsor. Na pewno ktoś chętny się znajdzie. Szczególnie w WJUG, który jest stosunkowo duży.
// koniec offtopu

Słaba znajomość języka

Pierwszą przyczyną niepisania testów jest moim zdaniem ogólna słaba znajomość języka w którym się pisze. Programista może być bardzo dobry, ale jeżeli jest na etapie poznawania języka programowania to w pierwszej kolejności chce by jego kod w ogóle zadziałał. Rozpoczęcie pisania testów jest znakiem, że dana osoba poznała język na tyle by nie poświęcać znacznej ilości czasu na walkę z kompilatorem, IDE czy konfiguracją.

Słaba znajomość narzędzi

Pierwsze testy to oczywiście proste „Dupa debug”. Bardzo szybko zniechęcają do pisania jakichkolwiek testów. Jednocześnie programiści nie poznają wyspecjalizowanych narzędzi. Tym samym doprowadza się do sytuacji, w której z jednej strony programista wie, że ma testować, ale z drugiej tego nie robi ponieważ brakuje mu warsztatu.

Kiepsko zaprojektowany kod

Nie ukrywam, że obecnie nie testuję całego kodu. Wynika to z tej prostej przyczyny, że nie da się w sensownym czasie przygotować testów. Architektura projektu jest niestety taka, a nie inna. Niektórych rzeczy nie da się przeskoczyć dlatego wolę odpuścić testy jednostkowe w niektórych przypadkach i opędzić przypadki w ramach testów integracyjnych. Jest to tańsze.

Brak czasu

Silnie związane z pojęciem deadline’u i „na wczoraj”. Zazwyczaj jeżeli goni nas czas i musimy wpuścić jakiś patch czy inny „hotfix” to odpuszczamy testy. Potem nie ma czasu, a jeszcze później sprawa się rozmywa.

Punkty 1 i 7

Czyli pycha i lenistwo. W pierwszym przypadku „mój kod jest tak zajebisty, że aż prawie jak ja jest zajebisty dlatego nie potrzebuje testów n00bie”. W drugim „nie chce mi się”… i to wyczerpuje temat.

7 myśli na temat “Dlaczego nie piszemy testów – obserwacja

  1. Podpisuje sie kazda konczyna. Moim zdaniem dopoki nie przeprowadzi sie 1 projektu tworzac testy, uzywajac narzedzi i na ZNANYM SOBIE FRAMEWORKU (bo jezyk to IMHO znaja wszyscy) – ale jesli po raz pierwszy mieszasz np. Springa + Vaadina + Spring MVC + JPA + Freemarker to tak jak piszesz – niech zadziala, a potem bedziemy myslec. Jeden projekt tak naprawde powinien byc produkcyjnym projektem 'nauki pisania testow’.

  2. Ja bym dodal, ze „ludzie to nie wiedza jakie sily drzemia w naturze (TDD)” nawet jezeli o tym przeczytali lub uslyszeli 100 razy. Tez tak mialem ale zaczalem i teraz nie wyobrazam sobie zycia inaczej.

  3. Ano. Każda technika jest tylko tak dobra jak jej użycie w praktyce. Jak obejrzałem co ludzie robią z testami, to mój początkowy entuzjazm dla unit testów bardzo mocno spadł.

  4. Jeśli chodzi o testy jednostkowe to z moich obserwacji wiara w ten twór jest tracona gdy pojawia się zbyt dużo jednostkowo-integracyjnych testów, które padają z byle powodu przy nawet drobnej zmianie. Drugą z rzędu przyczyną jest jak sam napisałeś – zjebany kod. Powód jest oczywisty – jak kod jest nietestowalny to testy nie powstaną;)

    Co do testów funkcjonalnych to sądzę, że bez QA ani rusz bo automatyzacja testów i ich utrzymanie jest zagadnieniem niebanalnym i z doskoku tego się nie zrobi.

  5. Jeżeli testy jednostkowo-integracyjne sypią się z byle powodu to oznacza, że kod jest zjebany…

  6. Za dużo zależności jest od czynników, których nie chcemy testować, to się jebią…

  7. Za dużo zależności == zły kod.

    To co opisywałem w Ekstremalnej Obiektowości. Klasa nie powinna mieć więcej niż dwie zależności. Tak jak człowiek jest wstanie obsłużyć tylko dwa narzędzia na raz (bo ma dwie ręce) tak samo klasa nie powinna korzystać z większej ilości innych klas. Wtedy dość łatwo jest stworzyć odpowiednie zaślepki na potrzeby testów.

Napisz odpowiedź

Twój adres e-mail nie zostanie opublikowany.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax