Nienawidzę pisania testów…

1

Tak, wiem, to pewnie źle. Ale nienawidzę tego. To jest żmudne, nudne, uciążliwe do kwadratu.

Jeśli nikt nade mną nie wisi i nie każe pisać testów, to zwykle albo zakładam, że to, co napisałem jest OK (jeśli to jest na tyle proste, że po prostu widać), albo testuję na bieżąco ręcznie, jeśli mam wątpliwości. Sam dla siebie piszę testy tylko wtedy, jeśli coś jest dla mnie naprawdę trudne i przewiduję, że bez tego nic nie zrobię.

Być może jak będą nade mną wisieć dostatecznie długo żądając, bym zawsze pisał testy do wszystkiego, cokolwiek napiszę, to mi to tak wejdzie w krew że tak jak każdy „rasowy programista” nie będę wyobrażał sobie pisać czegokolwiek inaczej jak tylko według test-driven design, a jak tylko ktoś powie mi / napisze to, co ja piszę teraz, to zrobię double facepalm (co niewątpliwie każdy z Was zaraz zrobi). Do tego czasu pozostaje mi zastanawianie się, czemu muszę tracić tyle czasu na coś tak żmudnego, jak pisanie testów.

0

moderatorzy chyba spia ostatnio. Ostatnimi czasy na tym forum coraz wiecej shitpostow sie pojawia od gimbów i żadne stosowne działania nie są w tym kierunku podejmowane..

9

Jak kiedyś będziesz pracował przy dużym projekcie, w którym nie ma testów i zaczną się różne dziwne rzeczy wywalać, albo ludzie zaczną zgłaszać błędy to sam się przekonasz, że warto pisać testy :). Plus testy to mega dobra dokumentacja. "Tracisz" czas na napisanie testu, ale później nie tracisz na rozkminianie o co Ci chodziło w tej metodzie/klasie/funkcji.

3

Czy jeśli dziś napisałeś poprawną funkcję/metodę i ją przetestowałeś ręcznie, to czy przetestowałeś ją dla każdego przypadku?
Czy dałbyś uciąć rękę za swój kod, gwarantując tym samym że będzie działał bezbłędnie w projekcie, którego LOC rozrośnie się do kilku milionów?

Nigdy Ci się nie zdarzyło zaprogramowanie czegoś, żeby po kilku miesiącach mieć problem w stylu "No kurde.... do tej pory działało".

Jeśli miałeś chociaż jedną taką sytuację to jest już pora by pisać takie testy, albo wiedzieć o ich pożyteczności. A jeśli nigdy nie miałeś takiej sytuacji, to ja z wielką chęcią spojrzałbym w jakiś nawet krótki fragment Twojego kodu.

3

Taaaaak... a bez dobrych unit testów robisz tak: uruchamiasz apkę, klikasz tu, klikasz tam, czekasz na zasilenie grida, klikasz tu i masz wynik. Oczywiście jak apka jest webowa to jeszcze IDE odpali Ci serwer www do tego....

A wiesz co robię gdy mam do tego ładnie zrobiony unit test? Wciskam w visualu Ctrl+R+A - tyle i już wiem czy jest poprawnie czy nie. Jakbym miał przeklikiwać się 20 razy przez wszystkie moduły po to żeby przetestować to czy tamto to bym się chyba zastrzelił.

Wygoda ;)

Ja wiem, że na studiach uczą pisać testy do metody typu dwa plus dwa, że to bez sensu etc. ale zaswiadczam Ci, że nauka nie pójdzie w las.

2

Aaa i bym zapomniał o najważniejszym! Testy "chronią" code base przed pisaniem spagetti code! Bo zanim napiszesz funkcję to dwa razy się zastanowisz, jak ja napisać, żeby test przeszedł i żeby test i funkcja była jasna i przejrzysta :).

1
  1. Testy automatyczne to dopiero któreś z kolei narzędzie w zapewnianiu niezawodności - dość efektywne, ale nie idealne.
    (jak piszę testy to mmi to się zawsze przypomina dowcipy o indukcji wg fizyków (dla 3 się zgadza, dla 4 się zgadza, dla 5 też... czyli prawda)).
  2. Warto zawsze patrzeć wg wagi zagadnienia. Jak robisz coś dla siebie, sam, z powodu "niedziałania" nikt nie straci, i nie zginie : to spokojnie możesz olać :-)

Kiedy pisać test:

  • robisz coś z zespołem i dłużej (mam 8 ludzi w zespole, ponad 150 projektów/modułów (nie żartuje), sam nie wiem co robiłem w zeszłym tygodniu) - testy to wygodne narzędzie do zapisywania uzgodnień biznesowych - inaczej byśmy za często zmieniali zdanie i kręcili się w kółko.
  • pojawił się błąd - tak zwany Bug Driven Test - jak wyszedł Ci bug, to znaczy, że czegoś nie ogarnąłeś i jest duże prawdopodobieństwo, że znowu coś wyjdzie w tym miejscu kodu. Warto więc przed naprawieniem strzelić Test. To chyba najbardziej efektywne testy!,
  • nawet jak piszesz sam i eksperymentujesz, ale projekt może dłużej działać - to warto sobie przygotować fundament pod testy. Czyli w każdej warstwie przygotuj sobie choć test jeden. Wybieraj frameworki i biblioteki pod kątem testowalności. (Na przykład takie Javowe JavaEE w praktyce całkiem obsysa jeśli chodzi o testowanie),
  • testuj rzeczy które mają znaczenie. Przykładowo w wielu projektach WEB - wygląd często decyduje o przyciągnięciu lub odepchnięciu nowych użytkowników, a mimo to CSSy się sypią i nikt nie umie ich testować (btw. niestety nadal nie znam dobrego i prostego narzędzia do testowania wyglądu z automatu),
    ale już JavaScript testuje się bardzo dobrze i dużo to daje jak robisz typową webówkę.

TDD faktycznie pomaga na design systemu i zmniejsza niechęć do testów trochę. Pisze się łatwiej...
Po pewnym czasie tak łatwo, że możesz wpaść w pułapkę zwaną London school of TDD - piszesz szybko i dużo testów... które są bezwartościowe.

Co do alternatyw na testy: Ogólnie to wiele można osiągnąć na poziomie kompilatora, chłopaki od dependent types coraz więcej ciekawostek pokazują ... ale zanim zaczniemy tak programować to trochę jeszcze czasu minie.

1

Docenisz testy kiedy zaczniesz pracować nad niebanalnymi funcjonalnościami albo refaktoruzację kodu. Uwierz, ulepszanie kodu, które skutkuje psuciem już istniejącej funkcjonalności jest wk*****jące i mało produktywne. Mając testy automatyczne przynajmniej wyłapiesz to szybciej.

1

Jeśli nikt nade mną nie wisi i nie każe pisać testów, to zwykle albo zakładam, że to, co napisałem jest OK (jeśli to jest na tyle proste, że po prostu widać), albo testuję na > bieżąco ręcznie, jeśli mam wątpliwości. Sam dla siebie piszę testy tylko wtedy, jeśli coś jest dla mnie naprawdę trudne i przewiduję, że bez tego nic nie zrobię.

Jeśli masz małą apkę to spoko, ale jeśli robisz coś większego to wcześniej czy później możesz dojść do sytuacji, kiedy zmiana jednej rzeczy w aplikacji może spowodować jakiś dziwny bug, który ujawnia się w jakiejś konkretnej sytuacji. Powiedzmy, że żeby temu zaradzić będziesz za każdym razem ręcznie sprawdzał wszystko czy działa. I okej - jak zaczynasz coś robić to odpalisz apkę, klikniesz dwa razy i widzisz czy działa. Narzut czasowy jakieś 10 sekund. No ale potem apka się rozrasta, Żeby posprawdzać wszystko będziesz potrzebował z minuty. A potem i z półgodziny nie starczy na ręczne przetestowanie wszystkiego.

Pisząc odpowiednie przypadki testowe można przyspieszyć sobie pracę i przetestować wszystko w parę sekund (czy nawet jeśli będzie to większa apka, to odpalenie wszystkich testów może trwać z kilka minut - ale to i tak szybciej niż byś to klikał samemu. Chociaż moim zdaniem testy trwające po kilka minut to też trochę patologia).

Można też zwiększyć niezawodność rozwiązań, bo jeśli zdefiniujesz konkretnie od a do z, jak aplikacja ma się zachowywać, to wystarczy, że odpalisz testy i sprawdzisz, czy dalej się tak zachowuje. To może cię ochronić przed błędami regresji ("działało, a nie działa").

Łatwiej też fiksować bugi. Gdy znajdziesz buga (które nie uwzględniły twoje testy), to piszesz przypadek testowy, i dzięki temu specyfikujesz jak system powinien się zachować. A potem fiksujesz buga i wiesz od razu "kiedy się zreperowało". Czyli masz szybką pętlę zwrotną nie działa - działa (czerwone czy zielone). A jak już zafiksujesz buga, to dzięki testom nie pojawi się ten sam bug w przyszłości (a raczej: jeśli się pojawi, to będziesz miał to wykryte od razu w testach)

Poza tym - czasem piszesz jakiś oddzielny moduł, który będzie dopiero później zintegrowany z resztą aplikacji. Nie możesz go ręcznie przetestować, bo po prostu nie bardzo się da (bo np. nie jest zrobiona jeszcze integracja z resztą projektu). Wtedy taki test może być twoim jedynym miejscem, w którym możesz faktycznie odpalić swój moduł (na tym etapie developerki)

Czyli testy są bardzo przydatne.

Chociaż zgadzam się z tobą, że nie zawsze się chce pisać (ale nie zawsze wszystko się chce - testy są nudne, ale takie właśnie mają być). Nie zawsze też wiadomo jak je w ogóle pisać, i w zasadzie co testować, co po łebkach, a czego testowanie można sobie w ogóle darować.

W każdym razie myślę, że pytanie nie powinno brzmieć "czy testować", ale "jak testować".

8

Z twojego wpisu można wywnioskować, że wg ciebie zadaniem testów jest tylko i wyłącznie wyłapywanie bugów.

Tymczasem to nie jest jedyna, ani nawet - zaryzykowałbym - w praktyce nie jest to wcale główna funkcja kodu testowego.

Po pierwsze, jest on żywą dokumentacją tego, jak działa system. To jest bardzo istotny atut. W praktyce zawodowej nie pracuje się tylko z własnym kodem, i to kodem np. sprzed tygodnia. Komentarze się starzeją, a aktualność testów jest wymuszona ich naturą. Kiedy dziedziczę po kimś skomplikowany kod, w którym nie wszystko rozumiem, ale testy są wyczerpujące i nienagannie napisane - idę poczytać testy, i wszystko staje się jasne. To jak najlepszy tutorial. Dobre testy to żywa specyfikacja systemu.

Po drugie, testy same w sobie wymuszają lepszy i zdrowszy design: np. stosowanie luźnych zależności, SRP i inne.

Wydaje mi się, że prawdziwe pytanie, które powinieneś sobie postawić, brzmi - dlaczego pisanie (i utrzymywanie) testów jest dla ciebie tak żmudne, że aż go nienawidzisz.

Moim zdaniem świadczy to o tym, że się po prostu nie umie pisać dobrych testów... ani - tym bardziej - kodu produkcyjnego z myślą o testowym.

To nie zarzut: jest to trudna umiejętność i wyższa szkoła jazdy dla zaawansowanych. Nawet programiści ze sporym zasobem doświadczenia mają z tym kłopot.

Warto na ten temat poczytać i pouczyć się od ekspertów. Polecam np. stronę i wykłady tego gościa: http://artofunittesting.com/ - to niezły guru właśnie od tego tematu.

testuję na bieżąco ręcznie, jeśli mam wątpliwości

Ile trwa to testowanie ręczne, jeśli wywołanie buga wymaga uruchomienia aplikacji, zaaranżowania pewnej sytuacji, przeklikania paru ekranów? Ile zabierze łącznie czasu, jeśli musisz powtórzyć wszystkie IDENTYCZNE kroki każdorazowo po naniesieniu poprawki, żeby sprawdzić, czy już działa? Pisanie testów jest żmudne, a TO nie jest żmudne? :))

0

Testy nie są po to, żeby testować czy coś działa zaraz po napisaniu.

2

Po nazwie tematu już myślałem, że to jakiś rozżalony gimnazjalista, który słabo napisał wczorajszy test gimnazjalny

4
kmph napisał(a):

Sam dla siebie piszę testy tylko wtedy, jeśli coś jest dla mnie naprawdę trudne i przewiduję, że bez tego nic nie zrobię.

Sam też mam takie podejście. Podejrzewam jednak, że mam trochę więcej doświadczenia niż Ty, i przewiduję, że więcej rzeczy jest naprawdę trudnych.

Być może jak będą nade mną wisieć dostatecznie długo żądając, bym zawsze pisał testy do wszystkiego, cokolwiek napiszę

Ależ testowanie wszystkiego nie ma sensu! Testować jednostkowo można logikę, nie interakcje, nie GUI, nie wymianę danych z innymi systemami.

Do tego czasu pozostaje mi zastanawianie się, czemu muszę tracić tyle czasu na coś tak żmudnego, jak pisanie testów.

Nie nazwałbym pisania testów żmudnym, no chyba, że robi się to bezmyślnie. W normalnym przypadku zaś trzeba myśleć - o przypadkach testowych, o tym co może pójść nie tak w kodzie, jak i o architekturze samych testów.

0

Tak czytam ten temat i wypowiedzi, ze 'docenisz testy jak bedziesz pracowac w duzym projekcie' i sie smieje pod nosem xD

Ja pracuje przy bardzo duzym projekcie, rozwijanym od ponad 10 lat, z ktorego korzysta wiele firm w Polsce i u nas w ogole nie ma testow, bo sie nawet ich nie da napisac :D Projekt jest tak stary i tak ogromny, ma tyle funkcjonalnosci, ze jego przepisanie nie wchodzi w gre. Sa pliki z klasami po kilkanascie tysiecy linii, w projekcie wykorzystuje sie ASP.NET WebFormsy i jednocześnie MVC (tak to mozliwe). Nowe rzeczy piszemy oczywiscie w MVC, ale pisanie u nas testow nie ma kompletnie sensu :D

4

Brałem udział w różnych kupiastych projektach, ale nigdy nie miałem tak, żebym nie mógł napisać testów do swojego kodu. Wszytko to kwestia odpowiedniej architektury i modularyzacji.
I nawet jeśli wszyscy inni piszą cały swój kod (łącznie z obsługą zewnętrznych źródeł danych) bezpośrednio w kodzie apki webowej, i nie mają szans na testy, bo potrzebują uruchomionego serwera www, żeby cokolwiek odpalić, to ja nie muszę. Mój kod zawsze może być porządny.

0

A wedlug mnie pisanie testow jest calkiem fajne. Szczegolnie jak sie zlapie flow.

Za to nigdy nie lubilem uruchamiac aplikacji by cos sprawdzic.

3

Testy to zło. Z testami są same problemy.

  • Koduję sobie jakiś banalny ticket, np. nowy load balancer do rozproszonego systemu plików, na bazie głębokiego AI biorącego pod uwagę obciążenie sieci, CPU, długość kolejek I/O i fazę księżyca. Napisałem to przez weekend, skompilowało się znaczy działa, wysyłam do recenzji.
  • Odrzucone z komentarzem "Brak testów".
  • No to napisałem testy, odpalam, czerwone. Szukam błędów.
  • Po dwóch dniach dostosowywania testów do dobrego kodu w końcu jest wszystko na zielono. Wysłałem do recenzji.
  • Odrzucone z komentarzem "Za małe pokrycie testami"
  • Przez dwa tygodnie piszę testy. Dużo testów. Rzygam testami. Przy okazji piszę nawet testy do nieswojego kodu. A później testy do testów.
  • W końcu sukces. Recenzję przeszło.
  • Jenkins jednak stwierdził "Test failures". Dziwne, u mnie działa.
  • Testy wykonują się za długo i zużywają za dużo RAMu i I/O i na jenkinsie lecą timeouty / kończy się HDD.
  • Kolejne dwa dni dostosowywania testów aby jenkins był zadowolony. W końcu sukces, wszystko na zielono.
  • W międzyczasie QA odpaliło swój zestaw testów. Stwierdzili, że coś się wywala, i przesunęli mój ticket do "In progress"
  • Przez trzy dni QA twierdzi, że kod działa źle i coś im popsuł, żeby na końcu stwierdzić, że mieli błąd w jakimś skrypcie i że to jednak ich wina.
  • W końcu upragniony merge.

(2 miesiące później)

  • Przy okazji jakiegoś refaktoringu czytam swój kod jeszcze raz i znajduję w nim 3 błędy. Żaden nie złapany przez testy.
1
V-2 napisał(a):

Z twojego wpisu można wywnioskować, że wg ciebie zadaniem testów jest tylko i wyłącznie wyłapywanie bugów.

Tymczasem to nie jest jedyna, ani nawet - zaryzykowałbym - w praktyce nie jest to wcale główna funkcja kodu testowego.

Po pierwsze, jest on żywą dokumentacją tego, jak działa system. To jest bardzo istotny atut. W praktyce zawodowej nie pracuje się tylko z własnym kodem, i to kodem np. sprzed tygodnia. Komentarze się starzeją, a aktualność testów jest wymuszona ich naturą. Kiedy dziedziczę po kimś skomplikowany kod, w którym nie wszystko rozumiem, ale testy są wyczerpujące i nienagannie napisane - idę poczytać testy, i wszystko staje się jasne. To jak najlepszy tutorial. Dobre testy to żywa specyfikacja systemu.

+1

Po drugie, testy same w sobie wymuszają lepszy i zdrowszy design: np. stosowanie luźnych zależności, SRP i inne.

A z tym bym polemizował. Widziałem już, jak w celu łatwiejszego testowania kodu, kod staje się "overengineered". Np. programista tworzy dodatkowe warstwy abstrakcji tam, gdzie nie są one wcale konieczne do rozwiązania zadania. Później ma się do czynienia z "pięknym" kodem o stu warstwach abstrakcji, w których nie można znaleźć, gdzie faktycznie jest wykonywana właściwa praca.

I później kończy się to tak:
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

1

Jeszcze jeden powód, dla którego testy działają mi na nerwy.

Zdaję sobie sprawę, że ten fakt niekoniecznie dobrze o mnie świadczy, jako o koderze… Ale gdy coś piszę, to zauważyłem, że dość często wprowadzam dość drastyczne zmiany w tym, co napisałem wcześniej.

Jeśli miałbym pisać testy na bieżąco, to każda taka zmiana automatycznie niesie za sobą konieczność wprowadzenia analogicznej zmiany w testach. To jest podwójnie upierdliwe i co gorsza, odciąga moją uwagę od tego, jak powinienem to wszystko ułożyć, żeby ze sobą współdziałało.

Nie jestem pewien, jak TDD mógłby tu coś pomóc. Teoretycznie TDD ma m.in. zapewnić, że ja sam rozumiem specyfikację funkcji, którą właśnie piszę. Ale jeśli za pół godziny zorientuję się, że ta właśnie specyfikacja wymaga zmian?

(Teoretycznie pewnie powieniem najpierw rozrysować sobie cały projekt na kartce, upewnić się, czy to ma sens, i dopiero potem implementować. Jeśli w trakcie pisania orientuję się, że funkcja x powinna zwracać coś trochę innego, niż zwraca, albo że lepiej przenieść funkcję y do klasy z, to znaczy, że coś tu jest nie tak, zgadza się?)

1

Ten fakt uzmysławia mi, jakie mam szczęście że nie muszę pracować z tobą w zespole

2

NIe wiem o co chodzi poprzednikowi... ale akurat ja lubię pracować z ludźmi, którzy często zmieniają swój kod. To znaczy, że się uczą i chcą naprawiać.

Jeśli za każdą zmianą w programie musisz dopasować testy to może są one zbyt natrętne (może Mockow używasz i weryfikyjesz wszystko ? (aka London School of TDD").
Dużo powinno się samo załatwiać przez toole do refaktoringu z IDE. Ale ideału nie ma. Dlatego testy nie są najlepszym narzędziem :P
Btw. lepiej się dowiedzieć, że specyfikacja wymaga zmian po 30 minutach niż po dwóch miesiącach.

0

To zwykle znaczy, że tworzą shit-kod i to po nich trzeba poprawiać.

3

No nie wiem. U mnie najgorszy shit kod to tworzą w kolejności:

  • "nieomylni" (od razu dobrze napisane, nie ma po co zaglądać i reviewować),
  • tacy co nie wiedzą co się dzieje i jak już coś zadziała to się boją ruszać,
  • ja.

Drugi typ jest czasem edukowalny, czasami zaskakująco dobrze. Pierwszy nadaje się tylko na awans zewnętrzny. Co do trzeciego - sam się nie polecę wywalić, ale po review zwykle się udaje z moich dzieł zrobić kod nawet czytelny (czyli znowu zmiany).

1

Podejrzewam że poza "Hello World!" to każdy program gdyby miał byc od początku napisany byłby za 2 razem napisany inaczej ;)

1

@Tokarz_

To zwykle znaczy, że tworzą shit-kod i to po nich trzeba poprawiać.

Wydaje mi się, że jest często odwrotnie. Najgorszy shit to zwykle pierwsza implementacja czegokolwiek, bo człowiek się dopiero uczy robić, poznaje problem, wskutek tego ten pierwotny kod nie jest optymalny pod kątem architektury choćby.

po nich trzeba poprawiać.

Poprawiać trzeba moim zdaniem częściej po tych ludziach, którzy coś piszą i wrzucają od razu na produkcję. Ktoś, kto ciągle zmienia podejścia sam po sobie poprawia, bo najpierw pisze shit-kod, a potem krystalizuje się to powoli i końcowy efekt jest lepszy

Jest fajny obrazek: https://medium.com/the-year-of-the-looking-glass/junior-designers-vs-senior-designers-fbe483d3b51e

Mam na myśli 2 pierwsze obrazki. Pierwszy to właśnie robienie wszystkiego "raz a dobrze" (czyli najczęściej: czasem słabo, czasem przeciętnie), a drugi to próbowanie różnych rozwiązań i selekcja najlepszych. Jak dla mnie to drugie podejście właśnie jest lepsze.

@kmph

Nie jestem pewien, jak TDD mógłby tu coś pomóc. Teoretycznie TDD ma m.in. zapewnić, że ja sam rozumiem specyfikację funkcji,
którą właśnie piszę. Ale jeśli za pół godziny zorientuję się, że ta właśnie specyfikacja wymaga zmian?

Dlatego TDD nie wszędzie się nadaje. Na etapie pisania exploratory code może być nie dość, że przeszkodą, to i stratą czasu (po co pisać testy do kodu, który ma zostać wyrzucony?).

Inna sprawa, że czasem same testy są zrobione zbyt szczegółowo i wchodzą w szczegóły implementacyjne. Zamiast testować publiczny kontrakt, to testują czy prywatne dane obiektu równają się tyle i tyle na każdym etapie wykonania (nie mówię, że nie można tego nigdy robić - ale już parę razy się sparzyłem właśnie na tym, że albo sam napisałem zbyt szczegółowe testy, albo np. pracowałem w projekcie, który trzeba było zrefaktorować i przy każdym refaktorze trzeba było zmienić testy - co trochę podminowuje sam sens istnienia testów ).

0
kmph napisał(a):

Jeszcze jeden powód, dla którego testy działają mi na nerwy.

Zdaję sobie sprawę, że ten fakt niekoniecznie dobrze o mnie świadczy, jako o koderze… Ale gdy coś piszę, to zauważyłem, że dość często wprowadzam dość drastyczne zmiany w tym, co napisałem wcześniej.

Jeśli miałbym pisać testy na bieżąco, to każda taka zmiana automatycznie niesie za sobą konieczność wprowadzenia analogicznej zmiany w testach. To jest podwójnie upierdliwe i co gorsza, odciąga moją uwagę od tego, jak powinienem to wszystko ułożyć, żeby ze sobą współdziałało.

Pewno uczysz się TDD z tutoriali i piszesz testy do klas zamiast do jednostek. Drastyczne zmiany w implementacji to norma, ale API może być względnie stabilne.

0

@somekind: co to dla Ciebie jednostka w tym kontekście?

1
Krolik napisał(a):
V-2 napisał(a):

Po drugie, testy same w sobie wymuszają lepszy i zdrowszy design: np. stosowanie luźnych zależności, SRP i inne.

A z tym bym polemizował. Widziałem już, jak w celu łatwiejszego testowania kodu, kod staje się "overengineered". Np. programista tworzy dodatkowe warstwy abstrakcji tam, gdzie nie są one wcale konieczne do rozwiązania zadania. Później ma się do czynienia z "pięknym" kodem o stu warstwach abstrakcji, w których nie można znaleźć, gdzie faktycznie jest wykonywana właściwa praca.

Można minimalizować to ryzyko. Np. wg mnie warto strzec się syndromu gonienia za iluzorycznym "100% pokrycia". Ta obsesja najczęściej pojawia się w projektach, gdzie wskaźnik taki jest wyliczany przez bezlitosny automat :) Nie jestem takim radykałem, nie wszystko trzeba testować

Albo mimo wszystko kiepski mógł być design wyjściowy - potem dopiero wtórnie poprawiany, żeby nagiąć go do wymogów testowalności. Prowadzi to do sztucznego "przebijania" warstw abstrakcji, które zostały że tak powiem krzywo położone za pierwszym razem, i nadmiaru rozmaitych wrapperów.

Myślę że twoja uwaga jest bardzo słuszna, tylko to jest jakby pułapka na bardziej zaawansowanym poziomie

Z tego co napisał OP wynikało, że w swoich oporach przed testami nie doszedł jeszcze do takich problemów, i do tego się dostosowałem.

I później kończy się to tak:
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

Dobre : )))

Od razu przypomniało mi się http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html a w szczególności przyśpiewka dziecięca pod "Are Javalanders Happy?" :D

Ale bądźmy uczciwi, to już nie wina pisania testów - przekombinować można samemu z siebie. Szczególną namiętność do tego przejawiają Javowcy. Chyba nieprzypadkowo i twój, i mój link to karykatury pisane w Javie : )

0
kmph napisał(a):

Jeszcze jeden powód, dla którego testy działają mi na nerwy.

Zdaję sobie sprawę, że ten fakt niekoniecznie dobrze o mnie świadczy, jako o koderze… Ale gdy coś piszę, to zauważyłem, że dość często wprowadzam dość drastyczne zmiany w tym, co napisałem wcześniej.

Jeśli miałbym pisać testy na bieżąco, to każda taka zmiana automatycznie niesie za sobą konieczność wprowadzenia analogicznej zmiany w testach. To jest podwójnie upierdliwe i co gorsza, odciąga moją uwagę od tego, jak powinienem to wszystko ułożyć, żeby ze sobą współdziałało.

Te częste drastyczne zmiany to właśnie czas, w którym kod zostaje nadziany największą ilością bugów. A te to dopiero są upierdliwe. Zwłaszcza, że najlepsze nie spieszą się z wyjściem na jaw i dadzą o sobie znać, gdy już nie będzie oczywiste, w którym momencie się wylęgły

Nie jestem pewien, jak TDD mógłby tu coś pomóc.

Czas między powstaniem a identyfikacją buga jest skrócony do praktycznego minimum.

Teoretycznie TDD ma m.in. zapewnić, że ja sam rozumiem specyfikację funkcji, którą właśnie piszę. Ale jeśli za pół godziny zorientuję się, że ta właśnie specyfikacja wymaga zmian?

To oczywiście możliwe. TDD daje to, że design musisz sobie w miarę skonkretyzować przed implementacją. Napisanie niedziałających jeszcze testów jest akurat bardzo szybkie, a przy odrobinie szczęścia już wtedy jesteś w stanie wyłapać już pewne błędy projektowe (jak po prostu to, że klasy się dobrze ze sobą nie spasują).

Programując tradycyjnie, czyli sobie improwizując, ten końcowy design i tak przecież musisz mieć, tylko trzymasz go podświadomie w głowie, a wtedy trudniej zauważyć, że coś jest z nim nie tak - tak samo jak w szachy trudniej gra się na ślepo

Oczywiście i tak możliwe jest, że co pół godziny trzeba będzie zmienić implementację - ale jest to przecież postęp w stosunku do konieczności zmieniania jej np. co 10 minut ; )

(Teoretycznie pewnie powieniem najpierw rozrysować sobie cały projekt na kartce

Całego projektu, to przecież niemożliwe. Jakichś jego wycinków. I właśnie taką formą rozrysowania jest napisanie testów, z tym, że ta "kartka" nie zostaje zmarnowana, bo masz już kod testowy, do którego trzeba już tylko dociągnąć implementację.

Uczciwie mówiąc ja nie jestem jakimś adwokatem TDD i nie uprawiam go w ścisłej formie. Co nie zmienia faktu, że staram się, żeby pisanie testów przeplatało się przynajmniej z implementacją, nawet jeśli implementacja idzie przodem. Nie najlepszą, choć często spotykaną praktyką jest wykończyć jakąś funkcjonalnosć i dopiero po wszystkim, "na deser", dorabiać do niej testy.

0
scibi92 napisał(a):

@somekind: co to dla Ciebie jednostka w tym kontekście?

Jednostka to odrębna całość.

1 użytkowników online, w tym zalogowanych: 0, gości: 1