[placebo_]

Test driven development - hot ot not? #programowanie

[Saly]

: No to naprawę państwa należy zacząć od naprawy pojęć

@MacDada: widziałem mnóstwo dyskusji w internecie na ten temat i każda konczyła się tak samo. Zresztą wystarczy przeczytać początek zalinkowanego przeze mnie artykułu

Tu wychodzi to pomieszanie pojęć. Jeśli Twój test korzysta z jakiś bibliotek, to nie jest to już test jednostkowy, a integracyjny – bo testowany kod integruje się z czyimś

[Hopsiup-siup]

@Saly:

Tak czy owak typ testu nie wpływa na to jak się pisze test. Może być szybko przy "integracyjnch" (bo to sam serwer HTTP i np. jakieś inne serwisy uderzane po HTTP których postawienie trwa milisekundy) a mogą być też wolne testy unitowe (ogromna ilość, długa inicializacja związana z słabymi bibliotekami)

Feature Small Medium Large
Network access No localhost

[Saly]

Zaprzeczasz sam sobie, ten podzial od googla z 2010 roku jasno mowi, ze testy wykorzystujace Network access są wolniejsze od tych, które tego nie robią

@Hopsiup-siup: to są cechy w stylu "od kiedy test staje się cięższy" a nie wszystko ma pasować. Jak napiszę testy E2E odpalające 100 serwisów, które nie dotykają systemu plików to mam na pewno "Large" a nie "Small"

[Hopsiup-siup]

@Saly: no jasne, tylko to co napisałeś wcześniej, że testy integracyjne mogą być szybsze od jednostkowych to przypadek, a nie zasada.

[MacDada]

każdy kod używa jakichś bibliotek np. biblioteki standardowej. Przy tego typu dyskusjach najczęściej widziałem problem pod tytułem "czym jest unit".

jak przepiszę kod z biblioteki na "mój" kod w obrębie modułu to nagle test stanie się unitowy a nie integracyjny?

@Saly: Problem wynika z tego, że dyskutujemy ogólnie, a ważny jest kontekst.

Jest różnica między biblioteką w stylu std::vector, a

[Saly]

no jasne, tylko to co napisałeś wcześniej, że testy integracyjne mogą być szybsze od jednostkowych to przypadek, a nie zasada.

@Hopsiup-siup: zgadzam się choć za bardzo nie wiem jak to się ma do dyskusji. Jak mam wolne testy to trudno mi się robi TDD, jak mam szybkie to nie. Typ testów nie ma tu znaczenia

I tutaj bardzo przydatny jest proces TDD

@MacDada: w moim rozumowaniu typ testów

[MacDada]

w moim rozumowaniu typ testów nie wpływa na to czy robimy TDD czy nie. Mogę się nie wpisywać o ogólną definicję (choć jak to często bywa: ciężko powiedzieć co autor miał na myśli) ale według mnie cała esencja TDD to ta pętla red/green/refactor i mogę ją osiągnąć używając testów E2E, integracyjnych czy unitów w zależności od tego co uznam za stosowane. W niektórych projektach będzie to 100% unitów, w niektórych 0%

TDD to jest proces, narzędzie. Służy do konkretnych celów. Oczywiście można wyklepać felgę przy pomocy młotka, ale niekoniecznie będzie to najlepsze narzędzie do zadania.

Więc pierwszym pytaniem jest: czy w ogóle będę pisać testy?
Drugie pytanie jest: jaki zakres funkcjonalności (wiem, błąd językowy, ale nadal pasuje mi używać tego słowa ;p) chcę testować?

[Hopsiup-siup]

@Saly: @MacDada: Imo typ testów ma znaczenie, jeżeli zaczniesz od testów E2E to bedzie to BDD, a jeżeli od jednostkowych to będzie to TDD.

[Saly]

@Hopsiup-siup: według wiki Behavior-driven development combines the general techniques and principles of TDD i sam też je traktuje jako przypadek specialny TDD. Tak czy owak esencja jest ta sama

[MacDada]

jeżeli zaczniesz od testów E2E to bedzie to BDD, a jeżeli od jednostkowych to będzie to TDD.

@Hopsiup-siup: Tu się muszę zgodzić z @Saly – BDD to wyspecjalizowany TDD – albo inaczej: BDD jest podzbiorem TDD. Czyli robiąc BDD, robisz TDD. Robiąc TDD, niekoniecznie robisz BDD.

[Hopsiup-siup]

@Saly: @MacDada:
Zgadza się, nigdzie nie napisałem, że tak nie jest.

Rozumiem co @Saly ma na myśli pisząc o procesie TDD,

Uważam, że TDD nie jest skomplikowane w implementacji i w zupełności wystarczy skupić