Dlaczego w teście Joela brakuje rozwoju opartego na testach?

Czytałem ten blog Joela Spolsky'ego o 12 krokach do lepszego kodu . Nieobecność Test Driven Development naprawdę mnie zaskoczyła. Chcę więc zadać pytanie guru. Czy TDD nie jest naprawdę warte wysiłku?

Rozwój oparty na testach był praktycznie nieznany, zanim książka Kenta Becka ukazała się w 2002 roku, dwa lata po tym, jak Joel napisał ten post. Powstaje zatem pytanie, dlaczego Joel nie zaktualizował swojego testu, czy gdyby TDD był lepiej znany w 2000 r., Czy uwzględniłby go wśród swoich kryteriów?

Sądzę, że nie zrobiłby tego z tego prostego powodu, że ważną rzeczą jest to, że masz dobrze zdefiniowany proces, a nie konkretne szczegóły tego procesu. Z tego samego powodu zaleca kontrolę wersji bez określania konkretnego systemu kontroli wersji lub zaleca bazę danych błędów bez rekomendowania konkretnej marki. Dobre zespoły stale ulepszają i dostosowują się, a także używają narzędzi i procesów, które są dobrze dopasowane do ich konkretnej sytuacji w danym czasie. Dla niektórych zespołów oznacza to zdecydowanie TDD. Dla innych zespołów nie tak bardzo. Jeśli przyjmiesz TDD, upewnij się, że nie jest to mentalność kultu ładunku .

Joel zajął się tym konkretnie w kilku miejscach.

Wyjaśnił, że testy rzeczy nie są w stanie wychwycić wielu ważnych problemów, szczególnie subiektywnych, takich jak „czy interfejs użytkownika tego oprogramowania jest do bani?” Według niego, nadmierne poleganie na automatycznych testach w Microsoft jest tym, jak skończyliśmy z Windows Vista.

Napisał, że według jego doświadczenia rodzaje błędów, które faktycznie znajdują użytkownicy, dzielą się na dwie kategorie: 1) te, które pojawiają się w powszechnym użyciu, które programiści znaleźliby, gdyby uruchomili własny kod przed jego użyciem lub 2) przypadki na krawędzi są tak niejasne, że nikt nie pomyślałby o napisaniu testów, aby je w ogóle uwzględnić. Stwierdził, że tylko bardzo niewielki odsetek błędów, które naprawił wraz z zespołem w FogBugz, jest czymś, co złapałyby testy jednostkowe. (Nie mogę teraz znaleźć tego artykułu, ale jeśli ktoś wie, który mam na myśli, nie krępuj się edytować link tutaj).

I napisał, że może to być więcej kłopotów niż jest to warte, szczególnie gdy twój projekt przeradza się w bardzo duży projekt z wieloma testami jednostkowymi, a następnie zmieniasz coś (celowo) i kończysz się bardzo dużą liczbą uszkodzonych testów jednostkowych. W szczególności wykorzystuje problemy, które mogą powodować testy jednostkowe, jako powód, dla którego nie dodał go jako 13 punktu do testu Joela, nawet gdy ludzie sugerują, że powinien to zrobić.

Sam Joel Spolsky odpowiedział na to pytanie w 2009 roku :

Joel: Toczy się debata na temat Test Driven Development ... czy powinieneś przeprowadzić testy jednostkowe na wszystko, tego rodzaju rzeczy ... wiele osób pisze do mnie po przeczytaniu Testu Joela, mówiąc: „Powinieneś mieć 13 tutaj: Testy jednostkowe, 100% testów jednostkowych całego kodu. ”

I to wydaje mi się zbyt doktrynalne w kwestii czegoś, czego możesz nie potrzebować. Cała idea zwinnego programowania nie polega na robieniu rzeczy, zanim ich potrzebujesz, ale na pomijaniu ich w razie potrzeby. Czuję, że zautomatyzowane testowanie wszystkiego, wiele razy, po prostu ci nie pomoże. Innymi słowy, zamierzasz napisać okropnie dużo testów jednostkowych, aby upewnić się, że ten kod naprawdę zadziała i na pewno dowiesz się, czy to nie działa [jeśli nie napisz testy] faktycznie działa nadal ... Nie wiem, dostanę za to taką płomienną pocztę, ponieważ nie wyrażam tego zbyt dobrze. Ale wydaje mi się, że gdyby zespół naprawdę miał 100% pokrycia kodu swoich testów jednostkowych, pojawiłoby się kilka problemów. Jeden, spędziliby strasznie dużo czasu na pisaniu testów jednostkowych i niekoniecznie byliby w stanie zapłacić za ten czas w lepszej jakości. Mam na myśli, że będą mieli lepszą jakość i będą mogli zmieniać rzeczy w swoim kodzie, mając pewność, że niczego nie zepsują, ale to wszystko.

Ale prawdziwym problemem z testami jednostkowymi, jak odkryłem, jest to, że rodzaj zmian, które wprowadzasz w miarę ewolucji kodu, zwykle psuje stały procent testów jednostkowych. Czasami wprowadzasz zmiany w kodzie, które w jakiś sposób psują 10% testów jednostkowych. Celowo. Ponieważ zmieniłeś projekt czegoś ... przeniosłeś menu, a teraz wszystko, co polegało na tym menu, jest tam ... menu jest teraz gdzie indziej. I tak wszystkie te testy się teraz psują. Musisz mieć możliwość wejścia i odtworzenia tych testów, aby odzwierciedlić nową rzeczywistość kodu.

W rezultacie, gdy twój projekt staje się większy i większy, jeśli naprawdę masz dużo testów jednostkowych, musisz zainwestować w utrzymanie tych testów jednostkowych, aktualizowanie ich i utrzymywanie ich przemijanie staje się nieproporcjonalne do wysokości korzyści, które z nich czerpiesz.

Nikt oprócz Joela nie był w stanie na to odpowiedzieć. Ale możemy wypróbować kilka powodów / obserwacji.

Po pierwsze, testy nie są nieobecne w teście Joela

• Testy są wspomniane dwa razy w 12 krokach bezpośrednio (10 i 12)
• Istnienie kompilacji jest jednym z pierwszych punktów. Ideą posiadania kompilacji jest uzyskanie możliwości sprawdzenia, czy się zepsują, więc rozmawiamy o testowaniu tutaj.

Po drugie, cała idea testu Joela (jak rozumiem) polega na szybkim zadawaniu pytań typu „tak-nie”. „Czy robisz TDD?” nie pasuje dokładnie (odpowiedź może brzmieć: „niektórzy z nas”, „dla tej części kodu” lub „wykonujemy test jednostkowy”).

Po trzecie, myślę, że nikt nie powiedział (nawet Joel), że te punkty, w których nie ma „jedynych wartych czasu” (nawiasem mówiąc, „czy programujesz”), po prostu są to dobre, szybkie pytania, które należy zadać, kiedy przyjdą w kontakcie z zespołem programistów, czy to jako przyszły członek zespołu, czy nawet jako klient - oto lista, którą przekazałem niektórym nietechnicznym osobom wokół mnie, które szukały wskazówek na temat tego, jak dobry / zły jest ich własny dział IT. To nie wszystko, ale naprawdę źle jest pokonać w trzy minuty.