Te całe #unittest i #tdd to jakaś masakra. Czas pisania testów do czasu pisania kodu jest jak 2:1 (a może 3:1), i więcej czasu spędzam myśląc "jak to przetestować" zamiast "jak to ma działać".
Powiedzcie, że kiedyś mi się ten wydatek czasu zwróci...
mam to samo, teraz pisze aplikacje sieciowa i musze robic mocki odpowiedzi z sieci - wiecej kodu jest w testach niz we wlasciwej aplikacji, ale w sumie mam pewnosc, ze przetestowane fragmenty dzialaja zgodnie z zalozeniem
@Yahoo_: Tak jakby równolegle. Tzn, najpierw mam "niedziałający test", a później dopisuję kod. A czasami najpierw kawałek kodu, a później test - bo jak mam kod, to czasami dopiero widzę jakieś konkretne ograniczenia, których wcześniej nie przewidziałem.
A mockowanie to już w ogóle masakra, którą może i rozumiem, ale nie do końca umiem zastosować ;)
@singollo: Lepiej je napisać przed właściwym kodzeniem. Jak będziesz pisał równolegle, to możesz zacząć nieświadomie pisać testy pod swój kod, a ma być odwrotnie.
@singollo: No mockujesz swoje zależność np. Zamiast uderzać do bazy sprawdzasz tylko czy zostają wywołana odpowiednia metoda.
Testy powinieneś pisać przed kodem w tdd. Wtedy się nie zastanawiasz jak przetestować bo każda linijka, każde zachowanie ma swój test. Potem jak znajdziesz buga to też wpierw piszesz test który go powtarza, a potem naprawiasz
@singollo: TDD i bycie agaile jest teraz poprostu bardzo na czasie i modne. O ile nie które rzeczy są napewno bardzo fajne jak to że masz automatycznie dokumentacje, czy testy pokazaujące regresje to jednak wydaje mi się ze podejscie pisania testów->kodu->refactor jest poprostu bardzo zależne od tego co robimy i jak wygląda projekt.
Java, C# bardzo fajnie się nadaje do tego typu programowania. Nie tylko ze względu na budowe języków,
@singollo: znajdz sobie jakas pozadna biblitoke do mockowania (ja w C# uzywam moq) - a jak masz wszedzie duzo zaleznosci do wymockowania to przeanalizuj kod (czasem sa to symptomy tego ze cos robisz nie tak - nie zawsze wyjatki to np. viewmodele, controllery etc). Imo do TDD trzeba pochodzic z rozsadkiem - nie koniecznie trzeba dazyc do 100% pokrycia ;> Poza tym nie ktore platformy strasznieee utrudniaja unit testy ->
Powiedzcie, że kiedyś mi się ten wydatek czasu zwróci...
#programowanie
@singollo: To jest w zasadzie to samo. Unittesty to bardziej sformalizowany zapis tego jak "to" ma działać.
Warto je pisać chociażby dlatego, że to prawie że darmowa dokumentacja.
A mockowanie to już w ogóle masakra, którą może i rozumiem, ale nie do końca umiem zastosować ;)
Testy powinieneś pisać przed kodem w tdd. Wtedy się nie zastanawiasz jak przetestować bo każda linijka, każde zachowanie ma swój test. Potem jak znajdziesz buga to też wpierw piszesz test który go powtarza, a potem naprawiasz
Umiejętności przychodzą z
Do mocków (i testowania ogólnie) polecam Mockito lub coś podobnego (zależy jaki język).
Java, C# bardzo fajnie się nadaje do tego typu programowania. Nie tylko ze względu na budowe języków,
Ale nowy kod staram się pisać znacznie lepiej ;)