[kaczoor]

Pytanie do programistów - czy w swojej pracy (komercyjnej) piszesz kod zgodnie z zasadami TDD (Test Driven Development)?
#programowanie #programista15k #programista25k

[szmichal]

@kaczoor: ksiazkowe TDD widzi się tak samo często w pracy crudziarza jak książkowe DDD, czyli wcale xd zresztą w 99% przypadkach i ofert TDD oznaczało tyle że piszemy unit testy i może integracyjne

[nad__czlowiek]

@kaczoor: @szmichal tak w ogóle sama idea pisania testów przed kodem to rak jakich mało. Nie jest to w ogóle intuicyjne ani praktyczne, samo dostarczanie kodu zajmuje 3-4 więcej czasu a wiadomo pracujemy w SPRINTACH czyli mamy dostarczać kod szybko. To nie MARATONY tylko SPRINTY wiec kod ma być dostarczany taśmowo

Klient kodu nie widzi czy był napisany przez brute-force-stack-overflow-copy-paste czy z użyciem CQRS, DDD, DDA czy innych chorób psychicznych

[poison64]

@kaczoor a gdzie opcja "nie pisze testów bo robię w technologii gdzie orkiestracje składa się z klocków" ? :)

[rolling_stone_with_no_hope]

@kaczoor: TDD to gówno. Nie mam pojęcia jak będzie wyglądał mój kod, jaki będzie miał Kontrakt i jakie API i mam testy pisać do tego? Bez jaj. Od razu jak się uczyłem tego to mi to nie pasowało. Wynik był taki, że siedziałem i ciągle testy poprawiałem. Produktywność jakoś -200% u mnie wyniosła.

[szmichal]

@rolling_stone_with_no_hope: w prawdziwym tdd to inny dev piszę testy a ty implementację na podstawie interfejsów a sam test powinien być prosty czyli input - output. Wiadomo, plus jakieś mocki ale tak to wg książek powinno wyglądać

[Pasterz30]

@kaczoor: tdd to gowno, to prawda. Podobnie jak scrum to jedna z rakowych ideologii.

[some_ONE]

Nie mam pojęcia jak będzie wyglądał mój kod, jaki będzie miał Kontrakt i jakie API i mam testy pisać do tego

@rolling_stone_with_no_hope: no właśnie zdaje się, że w idealnym świecie to zanim zaczniesz pisać kod powinieneś już wiedzieć jaki będzie kontrakt, bo dlaczego nie?

to, że zazwyczaj task nie jest w ogóle opisany i nikt się nawet przez 10 minut nie zastanowił jak ma wyglądać kontrakt i zachowanie to inna sprawa

[80kg]

Nie zdarzyło mi się

[adrninistrator]

Ja zawsze robię tdd, tak jest najłatwiej zaprojektować dobrą aplikacje

[kaczoor]

@adrninistrator ale nie każdy kod to jest projektowanie niewiadomo jakiej aplikacji. Czasami trzeba dodać mały feature do już istniejącej, wtedy też lecisz z TDD?

[adrninistrator]

@kaczoor: Tak, wtedy jak najbardziej robię tdd, bo robiąc najpierw test można naprawdę dobrze przemyśleć to w jaki sposób dany feature ma działać. No i testowanie przyspiesza programowanie o jakieś milion procent

[niko444]

@kaczoor tdd nie polega na pisaniu najpierw testow pozniej kodu, tdd oznacza pisanie ich jednoczesnie na zmiane raz test raz implementacja. Tdd jest fajne jak sie wie konkretnie co ma sie zrobic i jak cos zwraca konkretna informacje ale tak rzadko bywa wiec malo kto stosuje tdd w praktyce choc niektorzy mowia ze widza roznice czy kod byl napisany za pomoca tdd czy nie. A najgorsze jak robi sie cos co chwile

[horus666]

@kaczoor: Filozofia jak każda inna - nie daje odpowiedzi, a mnoży pytania dając jedynie fałszywe poczucie bezpieczeństwa. Przy kodowaniu trzeba przede wszystkim myśleć i żaden test nie zwolni z tego człowieka.

[adrninistrator]

@niko444: no ale przecież dostajesz wytyczne co dany feature ma robić. Wiadomo że nie zawsze wszystko wiadomo, co wychodzi właśnie w czasie pisania testów. Bo wtedy okazuje się że np. robi zamieszanie z już istniejącą funkcjonalnością, lub po prostu istnieją też różne edge casey. Wtedy trzeba się zatrzymać i dostać szczegóły. Pisanie z testami jest milion razy szybsze niż bez, wystarczy je nasmrodzic i wtedy można śmiało robić #!$%@? muje dzikie