Test Driven Development (TDD) a commity

Zastanawiam się, jak powinny wyglądać commity jeśli robi się TDD. Piszę sobie teraz pet projekt do zarządzania wydatkami i póki co moje commity wyglądają w ten sposób, że najpierw dodaje puste unit testy, potem ich implementacje a na końcu implementacje danego ficzera:

Nofenak napisał(a):

Zastanawiam się, jak powinny wyglądać jeśli robi się TDD. Piszę sobie teraz pet projekt do zarządzania wydatkami i póki co moje commity wyglądają w ten sposób, że najpierw dodaje puste unit testy, potem ich implementacje a na końcu implementacje danego ficzera:

W sensie rozwalasz innym osobom mastera/maina? WIem iż tych innych osób nie ma, ale jakby były to by master/main był rozwalony i niedałoby się bić skompilować?

Nofenak napisał(a):

Zastanawiam się, jak powinny wyglądać commity jeśli robi się TDD. Piszę sobie teraz pet projekt do zarządzania wydatkami i póki co moje commity wyglądają w ten sposób, że najpierw dodaje puste unit testy, potem ich implementacje a na końcu implementacje danego ficzera:

Z punktu widzenia TDD, w ogóle nie musisz używać gita, jak nie chcesz, więc rób co chcesz.

Ale zerknijmy na wady i zalety jakie taki styl pracy może mieć.

Zalety (dla piszącego kod):

• Zmusza do pisania testów najpierw, i to akurat jest dobre.

Zalety (dla zespołu):

• Żadne

Wady:

• Sztucznie podnosi ilość commitów na conajmniej dwa sposoby:
  • Po pierwsze, każdy commit jest 2x (bo osobno test, i osobno implementacja)
  • Po drugie - w normalnym cyklu TDD na wytworzenie jednego feature'a napisałbyś między 10-50 nowych testów, i odpowiednią ilość implementacji. Chcąc przed każdym testem robić commit, wyszło by Ci ich 20-100
• W historii są commity, na której jeśli ktoś zrobi checkout to testy nie przechodzą (to jest moim zdaniem mega słabe)
• Ciężko jest pracować z taką historią - jak zrobisz merge albo rebase, to pliki z testami najpewniej nie będą mieć konfliktów, ale pliki z implementacją już tak - więc point of failure nie będzie na testach, tylko na tym drugim commicie - może to prowadzić do bardzo tricky sytuacji.
• Może zachęcać do pisania dwóch testów na raz, commit, i potem implementacja (i wtedy się TDD trochę psuje).
• Nie po każdym teście zmiany się nadają do integrowania się z nimi, nawet jak praktykujesz TDD; więc nie po każdym teście jest sens robić push.
• Robisz pulla, i dostajesz 100 commitów od kogoś - macie konflikt w jednej z nazw. Co robisz? Rozwiązujesz konflikt 100x? Jedyny sposób jaki można sobie z tym poradzić to chyba tylko git rerere.

Ale wiesz że nie musisz robić commita po każdym save? Git ma się nijak do TDD, nie powinieneś commitować kodu który się nie kompiluje. Raczej nie potrzebujesz też wrócić do commita który ma testy bez implementacji więc to zupełnie bez sensu.

Odpowiedź na pytanie "Zastanawiam się, jak powinny wyglądać commity jeśli robi się TDD":

tak samo jak zawsze

obscurity napisał(a):

Ale wiesz że nie musisz robić commita po każdym save? Git ma się nijak do TDD, nie powinieneś commitować kodu który się nie kompiluje. Raczej nie potrzebujesz też wrócić do commita który ma testy bez implementacji więc to zupełnie bez sensu.

Odpowiedź na pytanie "Zastanawiam się, jak powinny wyglądać commity jeśli robi się TDD":

tak samo jak zawsze

Zastanawiam się czy to wszystko co robi OP nie jest po to żeby pokazać iż robi się TDD, no bo jak masz wydewelopowany feature to nie wiesz czy testy były pierwsze czy feature. No chyba iż zachowasz mnóstwo commitów które będę dokłądnie to pokazywać. Tylko w zasadzie co co? Żeby móc wpisać sobie do CV iż ma sie dowód na to iż zrobiło się projekt w TDD?

Ja preferuje commity, które są zawsze zielone. chodz o to, żeby git bisect miał więcej szans na powodzenie.
Nie znaczy to jednak, że robię commit co każdy cykl TDD. Raczej w jednym commit jest parę cykli TDD.

Poza tym, pytanie jest jaką macie politykę mergowania PR do master?

• po prostu merge
• squash merge - tarci się detale commitów i wychodzi jeden commit jeden feature
• rebase fast forward (nie lubię, bo nie widać jasno, gdzie w historii zaczyna się jeden feature, a kończy poprzedni)
• rebase + merge no-fast-forward (ja preferuję to).

MarekR22 napisał(a):

Poza tym, pytanie jest jaką macie politykę mergowania PR do master?

• po prostu merge
• squash merge - tarci się detale commitów i wychodzi jeden commit jeden feature
• rebase fast forward (nie lubię, bo nie widać jasno, gdzie w historii zaczyna się jeden feature, a kończy poprzedni)
• rebase + merge no-fast-forward (ja preferuję to).

To ostatnie to się chyba nazywa "bow-shape" history, nie?

Ja preferuję "rebase fast forward", bo nie wydaje mi się że historia zmian w kontroli wersji odpowiada funkcjonalnościom. Funkcjonalności się na siebie nakładają, plączą z bugfixami, refaktorami, etc. Chyba nie da się osiągnąć korelacji "commit <=> funkcjonalności".

Ja się zastanawiam czy osoby które tak dbają o historię commitów kiedykolwiek z tego skorzystali? Ja osobiście nigdy nie przeglądałem historii w ten sposób commit po commicie, historia jedynie mi się przydaje do namierzenia jiry i dyskusji o jakiejś zmianie, szczytem wykorzystania gita jak dla mnie było zrobienie cherry-picka (np jako hotfixa z aktualnej wersji do starej wersji którą supportujemy) co zdarzyło się jakieś może 10 razy w moim życiu.
Czy faktycznie macie tak zawiłe w utrzymaniu projekty że historia musi być czysta i jakie są scenariusze w których to robi wam jakąkolwiek różnicę? Czy chodzi po prostu o porządek dla porządku?

Miałem w zespole "purystę gita" który spędził dwa dni na "przepisywaniu historii" po zmergowaniu dwóch repo żeby jakoś wyglądała i osobiście dla mnie to były dwa zmarnowane dni robocze, ale może czegoś nie rozumiem.

obscurity napisał(a):

Ja się zastanawiam czy osoby które tak dbają o historię commitów kiedykolwiek z tego skorzystali?

Naprawdę nigdy nie korzystałeś z git blame / annotate?
Często jak nie wiem skąd się wziął dany kod, to patrzę w historię i dobry commit message bardzo pomaga.
Szczególnie jak trzeba sprawdzić, czy fix nie wprowadził innego bug-a.

Poza tym odpowiadam za Continues Integration i jak trzeba wycofać jąkąś zmianę, to dobra historia bardzo to ułatawia.

Poza tym jak wiadomo kiedy bug się pojawił, patrzenie w historię ułątwia zlokalizowania, jaka zmiana coś zepsuła.

Fakt nie korzysta się z tego często, ale to jest jak z czarnymi skrzynkami w samolocie.
Dopóki wszystko jest w porządku to jest to zbędny sprzęt/funkcjonalność, ale jak już problem jest to lepiej, żeby czarna skrzynka zawierała użyteczne informacje, a nie śmietnik.

MarekR22 napisał(a):

Naprawdę nigdy nie korzystałeś z git blame / annotate?

no przecież właśnie napisałem że tylko do blame mi to potrzebne, a to jak wyglądają commity przed czy po i w jaki sposób został zmergowany branch to mi nie robi różnicy, do wycofywania zmian faktycznie najwygodniej mieć zesquashowane commity, ale to praktycznie to samo, squash niby przeszkadza w cherry picku ale ile razy w życiu się zdarzyło że wycofuje się zmianę albo kopiuje częściowo?
Wydaje się że jedynie "rebase fast forward" może zrobić bałagan bo ciężko to cofnąć

że najpierw dodaje puste unit testy, potem ich implementacje a na końcu implementacje danego ficzera

Ale przecież nie o to chodzi w TDD, zaprezentowane podejście nie ma sensu niezależnie od systemu kontroli wersji. Przecież w TDD piszesz (w teorii) minimalny test który nie przechodzi (red), potem dopisujesz fragment kodu który ten test poprawia (green) a potem ewentualnie czyścisz (refactor). I to powtarzasz do skutku, ale po kawałku. Jeśli chcesz najpierw napisać wszystkie testy dla twojego expenses crud, a potem całą implementację, i to zawrzeć w dwóch commitach, to to nie jest TDD.

Już (minimalnie) więcej sensu miałoby commitowanie każdego kroku red-green-refactor, ale to w średniej wielkości funkcji miałbyś dziesiątki commitów. To można oczywiście robić na luzaka w Gicie (bo branche są lokalne i nie trzeba się nimi chwalić światu), i może miało by to sens w projekcie solo, ale w czymkolwiek realnym gdzie pracuje >2 osoby to też nie ma sensu.

Problem w tym, że te 2 pośrednie commity to są WIP (work in progress).

Add empty unit tests for expenses crud - czyli coś tam zacząłeś robić, spoko, ale t
Implemented unit tests for expenses crud - to już nie jest spoko, bo napisałeś testy, które failują. Czyli na tym stanie projekt może się nie zbudować, jeśli warunkiem zbudowania będą wszystkie testy na zielono. Tego typu testy powinny mieć jakiś skip ustawione, żeby test runner je sobie pominął.
Implemented expenses crud - to jest dopiero ficzer.

Czyli chcesz zrobić commitowanie na raty, co sprowadza dodatkowy bałagan. Ficzer jest koncepcyjnie całością (kod produkcyjny + testy), a nie że testy osobno, a osobno implementacja (no i nie do końca na tym polega TDD). Ktoś popatrzy na ostatniego commita i pomyśli a gdzie testy do tego?.

Tak samo potem powiedzmy, że rozbudujesz tego CRUDa. I bardziej elegancko byłoby zrobić commit, gdzie masz od razu wszystkie potrzebne zmiany: zmiany w kodzie produkcyjnym + dodatkowe testy (albo zmiany w istniejących testach).

Z drugiej strony jeśli piszesz projekt samemu, to możesz sobie commitować jak ci wygodnie. Chociaż jeśli miałbym w ogóle dzielić tego CRUDa na kilka commitów, to już wolał podzielić po kolejnych ficzerach (gdzie w każdym commicie byłby kod produkcyjny + testy do kolejnej mniejszej rzeczy):

Add delete for CRUD
Add update for CRUD
Add remove for CRUD
Add create for CRUD
Initial

to też byłoby bliższe TDD, które przecież też wcale nie polega na napisaniu wszystkich możliwych testów, a potem implementacji, tylko raczej się przeplata:
test -> implementacja -> test -> implementacja -> test -> implementacja

Nofenak napisał(a):

Zastanawiam się, jak powinny wyglądać commity jeśli robi się TDD. Piszę sobie teraz pet projekt do zarządzania wydatkami i póki co moje commity wyglądają w ten sposób, że najpierw dodaje puste unit testy, potem ich implementacje a na końcu implementacje danego ficzera:

Zasadniczo, można commitować kod na trzy sposoby:

1. Cały ficzer na raz.
2. Każdy bajt oddzielnie.
3. Dowolna opcja między 1. a 2.

Co więcej, nie trzeba się trzymać raz wybranego schematu na zawsze.
Po prostu wybierz sobie jak Ci pasuje.

Git daje wolność tworzenia, wolność eksperymentowania, porzucania pomysłów w celu zastąpienia ich nowymi, i wracania do tych porzuconych, gdy nowe okażą się gorsze.
Nie rozumiem, czemu ludzie z własnej woli chcą sobie wymyślać jakieś ograniczenia, typu: trzeba commitować, gdy zrobi się coś, a nie zrobi się czegoś, albo nie można commitować, jeśli testy nie przechodzą, albo projekt się nie kompiluje. Absurdalne, piramidalne bzdury, w ten sposób tylko utrudnia się sobie życie.

obscurity napisał(a):

Ja się zastanawiam czy osoby które tak dbają o historię commitów kiedykolwiek z tego skorzystali? Ja osobiście nigdy nie przeglądałem historii w ten sposób commit po commicie, historia jedynie mi się przydaje do namierzenia jiry i dyskusji o jakiejś zmianie, szczytem wykorzystania gita jak dla mnie było zrobienie cherry-picka (np jako hotfixa z aktualnej wersji do starej wersji którą supportujemy) co zdarzyło się jakieś może 10 razy w moim życiu.
Czy faktycznie macie tak zawiłe w utrzymaniu projekty że historia musi być czysta i jakie są scenariusze w których to robi wam jakąkolwiek różnicę? Czy chodzi po prostu o porządek dla porządku?

Miałem w zespole "purystę gita" który spędził dwa dni na "przepisywaniu historii" po zmergowaniu dwóch repo żeby jakoś wyglądała i osobiście dla mnie to były dwa zmarnowane dni robocze, ale może czegoś nie rozumiem.

Ja kiedyś robiłem raport comitow jednego z programistów który narobił syfu i szefostwo chciało żeby wykazać jak. Wtedy pelne gitflow mi pomogło bo mogłem wygodnie porobić screeny i wrzucić w docx i dopisać swoje wynurzenia na ten temat. Natomiast nigdy poza tym jednym przypadkiem przez ostatnie 5 lat mojej kariery nikt inny nie skorzystał z tej historii w projektach w których byłem. Co lepsze to gdybyśmy nie mieli gitflow to by nic nie zmieniło bo szefo chciał tylko screeny syfiastych miejsc a nie jak do tego doszło.

Zresztą sama historia nie ma za bardzo wpływu na projekt, po kilku latach rzeczy są zrobione tak jak są i trzeba się z tym pogodzić i wprowadzić zmianę na bazie tego co jest a nie dumać i myśleć że 2 lata temu było tak a rok temu tak.

Samo ttd to w sumie jakiś fancy sposób developmentu oparty na mchu i paproci. A jego najzabawniejsza podstawa jest fakt że przy unitach istnieje przekonanie o ich prawidłowości i braku bugów. Bo jak to tak unit test może mieć błąd? Skoro nie umiemy pisać kodu bez bugów to testów też nie. Nie ma znaczenia czy pierwsze jest jajko czy kura jak jajko nie ma białka a kura ma raka mózgu. TDD dla mnie jest mniej wygodny niż standardowe podejście i możliwy do wykonania praktycznie tylko przy nowych ficzerach więc w może połowie mojej pracy.

To co robisz z comitami to poniżej krytyki. Zrób sobie skrypt żeby Ci comitował co 5 min, ma to tyle samo sensu co to co robisz. Robisz comit dopiero jak masz kod który się minimalnie kompiluje a najlepiej to nie rozwala testów żeby pipe nie świecił się na czerwono.

TL DR
TTD to sojowa metoda stosowana przez twitterowych krzykaczy.

bagietMajster napisał(a):

przy unitach istnieje przekonanie o ich prawidłowości i braku bugów.

Nikt rozsądny tak nie twierdzi. Testy badają tylko to, co jego asercje. A w momencie pisania nie zawsze można wykryć wszystkie przypadki brzegowe, które powinny być pokryte asercjami.

Efektem TDD nie jest to, że się dostarcza bezbłędny kod, tylko że się dostarcza kod przetestowany. Więc wiele zależy od seniority kogoś kto pisze takie testy. Ile jest w stanie przewidzieć edge case'ów.

A samo TDD jako praktyka nie jest wystarczające do łapania edge case'ów. TDD jest dość liberalne i polega na tym, że pisze się failujący test, a potem tylko tyle implementacji, żeby test przeszedł na zielono np. napisana w TDD funkcja do obliczania silni mogłaby w efekcie wyglądać tak:

function factorial() {
   return 6;
}


assert.strictEqual(factorial(3), 6);

(zakładając, że ktoś najpierw napisałby asercję, a potem funkcję).

I to może być problemem. Samo pisanie w paradygmacie TDD nie gwarantuje, że kod będzie działać w różnych przypadkach. Potrzeba jeszcze programisty, który będzie umiał określić, jakie asercje należy napisać, żeby sprawdzić poprawność czegoś.

Ale to nie znaczy, że TDD jest słabe. To po prostu sposób działania, którego końcowy efekt zależy od umiejętności/doświadczenia/wysiłku danego programisty.

możliwy do wykonania praktycznie tylko przy nowych ficzerach

Dla mnie zawsze w praktyce było dokładnie odwrotnie, przy zmianach w istniejącym kodzie, a zwłaszcza przy naprawianiu bugów, TDD sprawdzało się świetnie. Dodajesz test, który udowadnia, że dany bug występuje, a potem poprawiasz buga. No ale to trzeba też mieć dyscyplinę, sama metodyka niewiele pomoże jak masz zespół krudowców dodających nullchecki gdzie popadnie (złe wspomnienia).

Nie rozumiem, czemu ludzie z własnej woli chcą sobie wymyślać jakieś ograniczenia, typu: trzeba commitować, gdy zrobi się coś, a nie zrobi się czegoś, albo nie można commitować, jeśli testy nie przechodzą, albo projekt się nie kompiluje. Absurdalne, piramidalne bzdury, w ten sposób tylko utrudnia się sobie życie.

Jak pchasz na feature branch niedziałający kod to nie ma problemu. Gorzej jak pchasz taki kod na mastera/maina

bagietMajster napisał(a):

Skoro nie umiemy pisać kodu bez bugów to testów też nie.

To dość oczywiste, pozostaje pytanie - co jest bardziej prawdopodobne:

1. błąd w jednym miejscu;
2. ten sam błąd, a do niego 10 odwrotnych błędów niwelujących działanie tego pierwszego?

TDD dla mnie jest mniej wygodny niż standardowe podejście

Z moich obserwacji wynika, że "standardowe podejście" to "nie mamy testów, bo manager nie pozwala". Nie nazwałbym tego wygodnym.

KamilAdam napisał(a):

Jak pchasz na feature branch niedziałający kod to nie ma problemu. Gorzej jak pchasz taki kod na mastera/maina

Zakładam, że to taka podstawowa zasada higieny, że pracujemy na jakiejś swojej gałęzi, a nie na masterze.

bagietMajster napisał(a):

Skoro nie umiemy pisać kodu bez bugów to testów też nie.

Z reguły testy mają mniej logiki i abstrakcji niż kod produkcyjny. Robisz jakiś setup, a potem sprawdzasz asercjami, czy się zgadza. Pisanie testów zwykle nie jest zbyt wymyślne. Struktura pliku z testami też jest raczej dość sztywna. Można niby zrobić zawsze buga w testach, np. sprawdzać w asercji nie tę wartość, co trzeba, ale to będzie raczej odizolowany w jakimś kejsie bug.

Kod produkcyjny natomiast pisze się bardziej swobodnie oraz używając większej liczby abstrakcji na raz, czy robiąc bardziej skomplikowane przekazywanie danych z jednego miejsca na drugie, jak również często trzymając mutowalny stan w środku systemu. W takich warunkach łatwo coś przeoczyć i zrobić buga, a bug ten często będzie nie wiadomo gdzie i może wpływać na pozostałe części systemu. Dlatego przydają się testy, które to sprawdzą.

Można powiedzieć, że kod produkcyjny to jak bycie pisarzem, a pisanie testów to jak bycie korektorem. Pisarz wymyśla treść, a korektor sprawdza, czy są zachowane wszystkie reguły. Chociaż oczywiście zarówno pisarz może zrobić błąd, jak i korektor może tego błędu nie dostrzec.

@bagietMajster Myślę że niechcący ktoś Ci przekazał mylne pojęcie tego czym TDD jest. TDD nie obiecuje programów bez bugów ani nie obiecuje "udowodnienia 100% poprawności".

TDD to po prostu technika projektowa i testowa, która może też służyć do specyfikacji wymagań, i wytwarzania oprogramowania inkrementacyjnie. Jest również pomocna w wytwarzaniu lepszego designu. I w zasadzie tyle.

Nikt kto praktykuje TDD nie twierdzi że to pomaga wymyślić programy "w 100% poprawne".

bagietMajster napisał(a):

TDD dla mnie jest mniej wygodny niż standardowe podejście i możliwy do wykonania praktycznie tylko przy nowych ficzerach więc w może połowie mojej pracy.

Trzeba sobie zdać sprawę również z tego, że nawet stosując TDD niekoniecznie trzeba tego używać do wszystkiego.
TDD najlepiej się sprawdza do pisania bibliotek czy niezależnych modułów, które mają działać w przewidywalny sposób (i wiadomo jaki).

Z kolei grzebanie w większej istniejącej apce (która się zachowuje dynamicznie i jej działanie jest uzależnione od różnych rzeczy) i dodawanie różnych ficzerów, które integrują ileś rzeczy ze sobą (więc ciężko to testować w izolacji), nie musi być dobrym kejsem dla TDD. Szczególnie jeśli robi się coś z GUI, np. frontend w React.

Myślę, że zamiast psioczyć na TDD, to po prostu można nie używać tej metodyki tam, gdzie jest niewygodna, a używać w tych miejscach, gdzie to ma sens.

LukeJL napisał(a):

Myślę, że zamiast psioczyć na TDD, to po prostu można nie używać tej metodyki tam, gdzie jest niewygodna, a używać w tych miejscach, gdzie to ma sens.

Z tego co się orientuję to chyba po to jest forum? żeby wyrazić swoją opinie na dany temat,? (a to że ta opinia nie idzie zgodnie z linią partii to inna sprawa)
Uważam że TDD jest sztuką dla sztuki. Ja nikomu nie bronię w tym robić, po prostu wyraziłem swoją opinie na ten temat.

bagietMajster napisał(a):

Uważam że TDD jest sztuką dla sztuki. Ja nikomu nie bronię w tym robić, po prostu wyraziłem swoją opinie na ten temat.

A piszesz testy? Nie z TDD, tylko czy piszesz testy w ogóle np. testy jednostkowe, już po fakcie?

Riddle napisał(a):

bagietMajster napisał(a):

Uważam że TDD jest sztuką dla sztuki. Ja nikomu nie bronię w tym robić, po prostu wyraziłem swoją opinie na ten temat.

A piszesz testy? Nie z TDD, tylko czy piszesz testy w ogóle np. testy jednostkowe, już po fakcie?

Tak, po fakcie - gdy już mam przyzwoitą pewność np. co do ostatecznego designu API oraz poznałem potencjalne problemy wynikające z danego podejścia.

Przecież nie będę pisał testów podczas prototypowania, lol.

Im bardziej skomplikowany problem tym testy są ważniejsze, przy testowaniu czy coś zostało dodane do bazy to widać gołym okiem obyło by się bez testów, ale jak jest jakiś algorytm i wydaje się, że dobrze rozwiązuje problem to przy szczególnych przypadkach może się wywalić, a testy są proste bo wiesz jak coś powinno się zachować, a nie jak to rozwiązać, a algorytm automatyzujący tą czynność często może być bardzo skomplikowany.

Im bardziej skomplikowany problem tym testy są ważniejsze, przy testowaniu czy coś zostało dodane do bazy to widać gołym okiem obyło by się bez testów, ale jak jest jakiś algorytm i wydaje się, że dobrze rozwiązuje problem to przy szczególnych przypadkach może się wywalić, a testy są proste bo wiesz jak coś powinno się zachować, a nie jak to rozwiązać, a algorytm automatyzujący tą czynność często może być bardzo skomplikowany.

A potem masz dzisiątki lub setki endpotów z których każdy ma dodać naście wartości do bazy i nagle robi sie problem nie do ograniecie manulanie, bo samą skalą Cie zabije.
Niigdy nie byłem jakimś fanem intensywnego testowania, a raczej wprost przeciwnie. Ale po tym jak hobbystycznie czy ostatnio w pracy, trafiły sie takie ilości danych że nie da sie ich sprawdzić ręcznie, mój swiato pogląd został brutalnie z weryfikowany. To nie musi być żaden skomplikowanych algorytm, prosta czynność wykonana 1000 razy na 1000 róznych danych, i edcasy same sie pojawiają.

Manualnie testować nie ma co sprawdzać strata czasu, jak automatycznie testy wychwycą, tylko zachowanie trzeba zdefiniować, a nad tym czasem trzeba pomyśleć, zastanowić się bo zwykle trzeba różne sposoby zakończenia funkcji/algorytmu sprawdzić jakieś brzegi.

bagietMajster napisał(a):

Z tego co się orientuję to chyba po to jest forum? żeby wyrazić swoją opinie na dany temat,? (a to że ta opinia nie idzie zgodnie z linią partii to inna sprawa)
Uważam że TDD jest sztuką dla sztuki. Ja nikomu nie bronię w tym robić, po prostu wyraziłem swoją opinie na ten temat.

Tak, a inni mają prawo uznać Twoją opinię za bezsensowną, a także obalać argumenty, które podałeś. (Co jest o tyle łatwe, że postanowiłeś walczyć z chochołem.)
Wolność wyrażania opinii działa w dwie strony.

(Żeby nie było, sam TDD na ogół nie stosuję.)

Riddle napisał(a):

bagietMajster napisał(a):

Uważam że TDD jest sztuką dla sztuki. Ja nikomu nie bronię w tym robić, po prostu wyraziłem swoją opinie na ten temat.

A piszesz testy? Nie z TDD, tylko czy piszesz testy w ogóle np. testy jednostkowe, już po fakcie?

Tak, piszę testy jednostkowe po tym jak zrobię zadanie.

bagietMajster napisał(a):

A piszesz testy? Nie z TDD, tylko czy piszesz testy w ogóle np. testy jednostkowe, już po fakcie?

Tak, piszę testy jednostkowe po tym jak zrobię zadanie.

Czyli piszesz testy już po napisaniu feature'a?

To mam pytanko do Ciebie:

• Jaki masz code coverage'a?
• Ile z tego code coverage jest puste, a ile faktycznie pokrywa kod? (tak że testy failują jak znajdą buga w tym miejscu)
• Jak często podczas pisania aplikacji uruchamiasz ją żeby sprawdzić czy działa nadal wporzo?
• Jak często, kiedy natrafiasz na miejsce trudne do przetestowania, po prostu stwierdzasz "aa, dobra" i zostawiasz to miejsce nieprzetestowane?
• Czy można się spodziewać że 80% Twoich testów to są testy jakichś helperów, a faktyczne mięcho Twojej aplikacji jest nieprzetestowane?