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

23

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?

Maniak
źródło
13
Artykuł został napisany w środę, 9 sierpnia 2000 r. (Około 12 lat temu). Nie dlatego, że TDD nie było w tym czasie, ale nie sądzę, że podobało mu się to w dzisiejszych czasach.
Mike
12
Test Joela jest tylko zbiorem ogólnych wskazówek. Nie wszystko, co „warte wysiłku” może się tam zmieścić.
yannis
2
Opracowałem własny, bardzo nieodpowiedzialny, niechlujny test, aby ocenić jakość zespołu programistów. Wspaniałą rzeczą jest to, że zajmuje to około 3 minut ... Przyjemny w teście Joela jest to, że łatwo jest uzyskać szybkie tak lub nie na każde pytanie. Nie musisz wymieniać linii kodu na dzień ani średniej liczby błędów na punkt przegięcia ... ” - podjęcie decyzji, czy Twój projekt skorzysta z TDD, zajmie więcej niż 3 minuty i, no cóż, , może wymagać obliczenia średniej liczby błędów na punkt przegięcia - dlatego nie ma go na liście
komnata
Przejdź do Joel Stack plz. To interesujące q.
Erik Reppen
Powinieneś rozważyć zaakceptowanie odpowiedzi, która prowadzi do cytatów i cytatów bezpośrednio od Joela, ponieważ nie jest on bardziej wiarygodny. Zobacz programmers.stackexchange.com/a/189493/6586
Bryan Oakley

Odpowiedzi:

30

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 .

Karl Bielefeldt
źródło
1
Również ... och, jakoś trafiłeś w TDD, czy punkt Kool Aid, prawda?
Erik Reppen
27

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ć.

Mason Wheeler
źródło
2
Właściwie masz rację. Zwykle MO Joela jest człowiekiem ze słomy. Jakby TDD nie złapał dla mnie żadnych błędów, więc nie może być dobrze. Co nieco nie zgadza się z twierdzeniem, że TDD nie polega na testowaniu, ale na projektowaniu. Opuszczone testy są bonusem. Lub argumentować, że niewielka zmiana przerwie wiele testów jednostkowych, co sugeruje, że po prostu robi to źle. Lub całkowicie przepisać zasadę SOLID przed atakiem. Tego typu rzeczy. Właściwie to jego zwolennicy używają logiki kołowej, a nie on.
pdr
7
Całkowicie zgadzam się z tymi komentarzami Joela. Myślę, że jeszcze większym problemem jest język - w wielu dynamicznych językach nie wyobrażam sobie robienia niczego bez testów jednostkowych - w jaki inny sposób możesz stwierdzić, czy zwykła literówka spowoduje jakiś problem, którego nie zobaczysz, aż do krytycznego za chwilę? W statycznie wpisywanych, skompilowanych językach zaprojektowanych w celu zmniejszenia liczby błędów odsuwasz się od wszystkich najprostszych błędów i najczęściej pozostają błędy logiczne. Zmniejsza to zapotrzebowanie na rodzaj pełnego zasięgu zapewnianego przez TDD.
Bill K
2
@MasonWheeler: Naprawdę argumentujesz, że bezpieczeństwo kompilatora / typu eliminuje potrzebę testów jednostkowych? Rozmyślnie ignorujesz zalety projektowania TDD, ale, co ważniejsze, musisz mieć cholernie dużo czasu na refaktoryzację czegokolwiek. Przeciwnie, okazało się, że jest odwrotnie: np. Programiści .NET, którzy stosują metodologię TDD, nagle czują się sfrustrowani ilością kodu, który muszą napisać, aby zadowolić kompilator, który jest coraz bardziej nieprzydatny.
pdr
2
@pdr: Poważnie argumentuję, że „potrzebą testów jednostkowych” jest przede wszystkim brak bezpieczeństwa typu. Nie będąc programistą .NET, nie mogę powiedzieć wiele o ich doświadczeniach, ale z własnego doświadczenia wynika, że ​​trudność w refaktoryzacji opiera się całkowicie na dwóch czynnikach: czy napisałem kod w pierwszym miejsce i czy autor dobrze napisał kod. (Uwaga: punkty 1 i 2 niekoniecznie są ze sobą silnie skorelowane!)
Mason Wheeler
3
@Pdr Testy jednostkowe nie dowodzą twojego kodu, są głównie sprawdzaniem składni, ale mogą być bardzo przydatne podczas programowania. Testy integracyjne i systemowe mają jednak o wiele większy sens. Również większość refaktoryzacji w językach o typie statycznym można udowodnić jako bezpieczną, w rzeczywistości to właśnie jest refaktoryzacja - zestaw znanych „bezpiecznych” operacji, które przekształcają kod bez wprowadzania zmian. W języku statycznym IDE często może dokonać tych zmian dla Ciebie i zapewnić ich bezpieczeństwo, co często jest niemożliwe w dynamicznych językach, które w związku z tym wymagają testów jednostkowych, aby pomóc (nie udowodnić) tego samego bezpieczeństwa
Bill K
25

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.

Ross Patterson
źródło
2
Naprawdę? Nie zgadzasz się na opublikowanie własnej odpowiedzi Joela na pytanie PO?
Ross Patterson
1
Trudno się domyślić. Niektóre osoby używają głosowania w znaczeniu „akceptuję”, a nie „jest to przydatne”. To oczywiście powinna być zaakceptowana odpowiedź, ponieważ jest ostateczna.
Bryan Oakley,
Nigdy nie pracowałem nad projektem, który miałby 100% pokrycie testowe. Ale jeśli masz 0% pokrycia testowego ... ... to dość wymowne.
Kzqai
Dziękuję Ci! Myślę, że należy to zaznaczyć jako zaakceptowaną odpowiedź.
Jalal
5

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.

Jaskółka oknówka
źródło
3
„Czy robisz TDD?” z pewnością pasuje jako pytanie typu „tak-nie”. Rozumiem przez to pytanie, na które każdy odpowiada stanowczym „tak”, co w rzeczywistości oznacza „nie”.
yannis
2
@YannisRizos: Podobnie jak „Czy używasz najlepszych narzędzi, które można kupić za pieniądze?” (Tak ... dobrze ... z rozsądku.) I „Czy programiści mają ciche warunki pracy?” (Ohhhh tak ... dobrze ... zależy od twojego punktu odniesienia dla ciszy, jak sądzę.)
pdr
@pdr Zależy od tego, czy uważasz cichy dźwięk syren dochodzących przez otwarte okna.
Robert Harvey
Ponadto „Tak, wykonuję projektowanie odgórne ”. ;)
Izkata