Przede wszystkim nie chciałbym urazić miłośników testów i TDD, być może zwyczajnie tego nie rozumiem.

Unit testy nie tylko stają się coraz popularniejsze ale zostały już w pewnym stopniu standardem.

Co zastanawia mnie najbardziej, czy dobrze napisany kod, który przewiduje wszystkie możliwe outputy i inputy musi w ogóle być testowany? A może wychodzi na to samo?

Analizuję to i wnioski są takie: piszę kod który testuje inny kod. Co za tym idzie, w przyszłości będę pisał testy, żeby przetestować testy.

Czy nie jest to przerostem formy nad treścią? Jeśli nie chodzi tutaj o rozbicie kodu na mniejsze elementy to po co to wszystko tak naprawdę?

No i ostatecznie, czy "dobry" kod w ogóle trzeba testować ?

Tu nie chodzi o to czy Ty przewidzisz coś, tyko o to czy po zmianie/aktualizacji kodu nie wysypie sie coś w innym miejscu. Generalnie pisanie testów daje same plusy. Minus to czas.

To nie do konca jest prawda. Ok, na poczatku, moze poswiecisz minimalnie wiecej czasu by napisac testy ale z wlasnego doswiadczenia to oszczedza cala mase czasu w przyszlosci.
Wlasnie skonczylismy pracowac nad dosc skomplikowanym serwisem, ktore analizowal w ciul danych. Od poczatku byly pisane testy (TDD). Po paru miesiacach trzeba bylo zmienic pare dosc istsotnych klas. Dzieki testom, ktore juz posiadalem raz ze nie balem sie robic zmian, dwa ze zaoszczedzilem kupe czasu bo juz nie musialem sprawdzac czy wszystko chodzi i spedzac godzin na testowaniu. Od odpalilem testy i juz mialem pewnosc ze wszystko jest ok.

Rowniez pisanie testow zaoszczedzilo mi kupe czasu wpisaniu klas. Oryginalnie dane wejsciowe byly bardzo duze i skomplikowane. Przygotowujac testy przygotowalem rowniez dane wejsciowe ale juz nie tak duze jak oryginalnie bo nie bylo takiej potrzeby. Pozniej piszac klase latwiej a przez to szybciej mi sie pisalo kod bo wrazie jakiegos debugowania bez problemu moglem sprawdzic co napsulem majac do analizy mniejszy zbior danych.


Juz sa biblioteki ktore testuja testy. Nie musisz nic sam pisac

Już nie musisz
https://github.com/infection/infection
Narzędzie do sprawdzania jakości testów.

Co do samych testów to generalnie ilość h spędzonych na pisaniu dobrych testów oszczędzi Ci x razy więcej czasu w przyszłości i pozwoli uniknąć bugów na które trzeba będzie poświęcić czas a jest to bardzo dużo bo wlicz czas komunikacji klienta z 1-szą linią supportu, identyfikację problemu czy faktycznie problem istnieje, potem przekazanie tego problemu do działu Dev, taki Dev sobie potem musisz odtworzyć błąd, znaleźć go i poprawić.

Aha. Co do TDD jak i samych testów to polecam bardzo mocno pisać testy regresyjne - testy które sprawdzają czy błąd więcej się nie pojawi. Piszesz sobie najpierw test do znalezionego kodu który ma buga. Powienien być zielony. Potem porawiasz test do oczekiwanego reultatu - staje się czerwony. Potem poprawiasz kod z błędem i test wraca do zielonego. Tym oto sposobem zabezpieczyłeś kolejny kawałek kodu testami i unikasz ponownego pojawienia się błędu.

Jeśli nie leży Ci metodyka TDD to równie dobrze możesz pisać testy do kodu - to jest częściej sportkana praktyka bo ciężko się przestawić z prototypowania kodu w testach a potem implementowanie go.