[FEAofTruss]

23/100 dni z książką

Trzy prawa TDD

“Możemy zdefiniować trzy następujące prawa:
Nie można zacząć pisać kodu produkcyjnego do momentu napisania niespełnionego testu jednostkowego.
Nie można napisać więcej testów jednostkowych, które są wystarczające do niespełnienia testu, a brak kompilacji jest jednocześnie nieudanym testem.
Nie można pisać większej ilości kodu produkcyjnego, niż wystarczy do spełnienia obecnie niespełnionego testu.”

[Więcej infomacji]


#feaoftruss #czystykod #programowanie #programista15k #webdev #gamedev

Podobało się? To zaplusuj i zapisz się do wołania (link w stopce)

************

[Chcesz być wołany?]

[FEAofTruss]

Wołam zainteresowanych (49) z listy FEAofTruss
Możesz zapisać/wypisać się klikając na nazwę listy.

Sponsor: Grupa Facebookowa z promocjami z chińskich sklepów

Masz problem z działaniem listy? A może pytanie? Pisz do IrvinTalvanen

! @FEAofTruss @mikasjp @vorio @MAT3N @Trustm3 @wszystkiefajnenickisazajete @avangarda @mozetenbedziewolny @PhatFarm05 @owocbananowca @pan_cziken @Tojtek @Anon95 @kMarek @JachuPL @maykel @ugotowany_kamien @Movet @se_czytam @MaNiEk1 @pieczony_ziemniaczek @ogib @adish24 @denis-szwarc @krypsi @nonsplit @krasnoludkolo @Gigantyczny_Bebech @legitAccount @hit_malinowy @Efilnikufesin @kafapre @skim @udips @paganek @emaq @de-nuke @kolargolo @

[FEAofTruss]

Wrzucam dzisiaj fragment, który nie do końca rozumiem - czy ktoś mógłby napisać swoją interpretację punktu 2?

[krasnoludkolo]

@FEAofTruss fajne jeśli ma się jasno zdefiniowane wymagania które za 5 min się nie zmienią

[krasnoludkolo]

No i oczywiście

Po co mam testować skoro wiem, ze działa ( ͡º ͜ʖ͡º)

[zakopiak]

@FEAofTruss: Podobnie jak w wielu innych uogólnieniach - nie należy nadinterpretować. Może się okazać, że w skrajnym przypadku będziemy pisać naprzemiennie po jednym znaku testu i kodu. ;-)

[nilphilus]

@zakopiak: no tak, storyjka po storyjce. Test, kod, test, kod. - > produkcja.

[Przegrywek123]

@FEAofTruss: przedwczoraj jakoś się zabrałem w końcu i przeczytałem tą książkę całą, ale na moje ona przegina w drugą stronę. Np. postuluje żeby było tylko jedno użycie assert XD Czyli na sprawdzenie obiektu mającego 5 pól, napisz 5 testów. Niektóre rzeczy też już nie przystają, np żeby nie robić konstruktora domyślnego, problem w tym że spring i hibernate bez tego w ogóle nie potraktują tego jako encji itp

[rzezol]

@FEAofTruss Testy jednostkowe? A po co to komu potrzebne, a do czego? Ja tam wolę mieć kontrolę nad kodem ( ͡º ͜ʖ͡º)

[dog_meat]

@FEAofTruss: powodzenia z podejściem TDD, jak masz naprawić problem związany z przetwarzaniem równoległym (np race condition). Test jednostkowy raczej Ci tego nie złapie, więc trzymając się ściśle TDD nie możesz rozwiązywać takich problemów

[s.....a]

@dog_meat: do takich testów to tym bardziej potrzebujesz testów jednostkowych i dodatkowego kodu który pozwoli jakoś orkiestrować wątki żeby wykonywały się dokładnie w tej kolejności która powoduje bug. Ogólnie testowanie współbieżnego kodu to wyższa szkoła jazdy i warto spędzić trochę czasu żeby napisać kod umożliwiający efektywne testowanie go.

Zresztą jak inaczej naprawiać te bugi? Dodawać randomowe sleepy w kodzie aż bug się zamanifestuje, naprawić bug, usunąć sleep i czekać na regresję

[dog_meat]

@sakfa: w jaki sposób chciałbyś w teście jednostkowym zreprodukować tego typu problemy, skoro są niedeterministyczne? Tzn, jeśli zauważysz że jest taki problem, to wg TDD powinieneś napisać najpierw test, który zawsze będzie czerwony do czasu napisania poprawki. Natomiast przy takich problemach test będzie czasem czerwony, czesne zielony.

[s.....a]

@dog_meat: musiałbyś mi podać konkretny przykład to ci powiem jakbym do tego podszedł. W praktyce kod podatny na race condition to spory smród, zamiast go testować najprawdopodobniej starałbym się go najpierw usunąć a potem napisać test do już deterministycznego kodu, pełna zgoda że TDD jest tu raczej bez sensu. Zresztą wcześniej się źle wyraziłem, testowanie współbieżności to raczej poziom wyżej niż testy jednostkowe, to już trochę bliżej testów integracyjnych.

Ale gdybym

[dog_meat]

@sakfa: właśnie o tym piszę, że TDD się tu nie sprawdzi, skoro sam piszesz, że wywaliłbyś kod, napisał od nowa a później test.

Natomiast odnośnie tego to zdecydowanie się tak nie zrobił. Kod nie powinien mieć żadnych wytrychów na potrzeby testu

[s.....a]

Kod nie powinien mieć żadnych wytrychów na potrzeby testu

@dog_meat: nie zgadzam się z tym, brzmi mi jak jakiś dziwny dogmat typu 'nigdy nie należy testować na produkcji'. Jeżeli wytrych ułatwi i uprości test to czemu go nie dodać?

Z dependency injection też nie korzystasz? Przecież cały ten wzorzec to jeden wielki wytrych w kodzie żeby ułatwić testowanie.

[dog_meat]

@sakfa: DI złoży do oderwania abstrakcji od implementacji. Dzięki temu można w razie czego łatwo zmienić implementację. A że ułatwia to testowanie to tylko przyjemny efekt uboczny

[s.....a]

DI złoży do oderwania abstrakcji od implementacji

@dog_meat: no nie, do tego służą po prostu interfejsy. Nie musisz mieć DI żeby oderwać abstrakcje od implementacji:

interface Dao { }
class MysqlDao extends Dao { }

class App {
Dao dao = new MysqlDao();
...
}

Jest oderwana abstrakcja od implementacji? Jest. Mamy DI? Nie.

Ta najbardziej punktowana odpowiedz na SO: https://stackoverflow.com/a/130862 wspomina że największą zaletą DI jest właśnie izolacja klas na

[dog_meat]

@sakfa: tylko jeśli w wielu miejscach w kodzie używasz new MyClass() to nadal zmiana implementacji jest ciężka i tu właśnie z pomocą przychodzi DI

[s.....a]

@dog_meat: racja. Nie mówię że DI jest wytrychem na potrzeby testów tylko i wyłącznie. Jest też oczywiście używane do innych rzeczy.

Ale przynajmniej w mojej praktyce widziałem wiele klas majacych tylko 1 implementację i tworzonych tylko w jednym miejscu i i tak były przekazywane jako argument konstruktora tylko i wyłącznie po to żeby przekazać ich inną implementację w teście. Jak to inaczej nazwać jak nie wytrych na potrzeby testów? :)

[dog_meat]

@sakfa: na potrzeby testów używa się tego często i jest użyteczne w tej roli

[s.....a]

@dog_meat: no więc jak to się ma do:

Kod nie powinien mieć żadnych wytrychów na potrzeby testu

W sumie #!$%@?ąc od DI, dlaczego?