W trzecim odcinku rozmawiam z Adamem Kosińskim – programistą, prelegentem, aktualnie kodzącym C# w Londynie.
Tematem przewodnim są testy jednostkowe – nasza wspólna pasja. Gadamy zarówno o najlepszych jak i najgorszych praktykach. Przestrzegamy też na to uważać podczas przygody z testowaniem. Zastanawiamy się również dlaczego czasami testy nie spełniają oczekiwań programistów i… i wiele więcej :).
Konkurs: dzisiaj rozdaję licencję na NCrunch. Jak miło! To niewiarygodne narzędzie otrzyma autor jednego z komentarzy pod niniejszym postem. Piszcie, piszcie, piszcie! Dzielcie się uwagami, opiniami. Co sądzicie o DevTalku i o tym odcinku? Co byście zmienili, a co się podoba? Nie trzeba napisać komentarza pozytywnego aby być wziętym pod uwagę podczas rozdania NCruncha :).
Uwaga: dzisiejszy odcinek powinien brzmieć lepiej niż poprzednie… bo już nie muszę robić wszystkiego sam! Zgłosił się do mnie Krzysiek Śmigiel wyciągając pomocną dłoń gotową zająć się obróbką “surowego” materiału audio. To zajmowało mi masę czasu, więc pomoc przyjąłem bez chwili wahania. Super, dzięki!
Logo: w poprzednim odcinku został ogłoszony konkurs na logo. Zwyciężył Rafał Sańda przysyłając projekt, który bardzo mi podpasował. Już teraz jest on wykorzystany na twitterze, fejsie, itunes itd. Wypas i awesome, dzięki!
Montaż odcinka: Krzysztof Śmigiel.Ważne adresy:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
03 – O testach z Adamem Kosińskim | DevTalk
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl
Z odcinka na odcinek jest coraz fajniej :)
Jednak chciałbym się przyczepić do początku.
Osobiście nie jestem fanem zwrotu “Bądźcie devzdrowieni” :P
Później “Ogłoszenia drobne” wydają się być bardzo mechanicznie zaprezentowane. Czytałeś to z kartki? Postaraj się może przy tej części o więcej luzu tak jak podczas rozmowy.
Rozumiem, że początki są bardzo trudne i jestem pod ogromnym wrażeniem, że się tego podjąłeś. Z odcinka na odcinek jest coraz lepiej :)
Nareszcie powstał polski podcast, którego warto słuchać. Oby tak dalej.
Na a ja mam zagwozdkę, bo nie mogę z czystym sumieniem puścić tego na all@moja-firma.pl. Wchodząc w skórę juniora lub generalnie kogoś kto nigdy nie pisał testów, albo pisał, ale nie w cyklu TDD, to bym znalazł tu sporo argumentów, że nie warto się w to pchać. IMHO obietnica, którą składa TDD to nie “hype”. Jeśli coś nie idzie to jedyną odpowiedzią jest “try harder” – jakby to głupio nie zabrzmiało. Dla mnie 7 lat zabawy z testami to niesamowita przygoda okupiona momentami znacznymi spadkami samooceny, ale “expert beginnerem” już byłem i nie chcę tam wracać.
Zabrakło mi pewnego uporządkowania np.: po początkowym zachłyśnięciu się testami automatycznymi przychodzą zwątpienia – i to jest ok. Jednak nakaz “rób średnik w średnik” tak jak każe Kent Beck czy Uncle Bob, nie jest żadnym zabobonem. To jest po prostu etap nie do pominięcia w nauce. Kolejnym są te wszystkie “ok, ale…”. Tu pojawia się zagrożenie p.t. “ja wiem lepiej”. Dalej już przychodzi nirwana, że nie ma żadnych “ale” – jest tylko krytyczny umysł :))). DHH moim zdanie poległ strasznie i ciszej nad tą trumną, bo poza tym dobre rzeczy robi i szkoda, żeby się pociął…
Słusznie mowa o _złych_ testach jako balaście. Wchodzi tu w grę oczywisty fakt – ktoś kto pisał nienajlepszy “normalny” kod, będzie – a może to trwać b. długo bez zewnętrznego wsparcia – pisać zupełnie beznadziejny kod testowy. I trzeba sobie z tym jakoś radzić. Podobnie w reakcji na odgórny nakaz “teraz piszemy małe klasy i krótkie metody” kod automatycznie nie stanie się lepszy… tylko gorszy (czasem jednak lepszy jest 8-tysięcznik w stylu “transaction script” niż 80 źle nazwanych klas, z pokrywającymi się odpowiedzialnościami). Bez oświecenia czemu to właściwie służy nigdzie się nie zajedzie. Wracając do testów to trzeba się nauczyć słuchania tego co one nam “krzyczą”, zrozumienia skąd się biorą trudności. Na tym przystanku albo się wysiada, albo przyznaje przed samym sobą “wydawało mi się, że umiem programować, ale to nie prawda – trzeba wrócić do szkoły”.
Zgadzam się z @Kajetan, że z odcinka na odcinek jest coraz lepiej.
A mi tam odcinek się podobał:) Nigdy nie myślałem o testach jako o dokumentacji. Ale człowiek się całe życie uczy a i tak głupi umiera:)
Dzięki za super robotę jaką wykonujesz procent:)
Kajetan,
Dzięki :).
Nie czytam nic z kartki, po prostu mówienie czegoś “do mikrofonu”, bez nikogo słuchającego po drugiej stronie, jest strasznie trudne. Te części bez gościa nagrywam po kilkanaście razy i wiem, że brzmi to mega-nienaturalnie i drętwo, ale może się w końcu wyrobię. Nie mam pomysłu jak inaczej to poprawić poza ćwiczeniem.
Orientman,
Prawda, na pewno paru rzeczy zabrakło, ale właściwie DevTalk nigdy nie będzie “tutorialem” dla początkujących. Co prawda każdy odcinek planuję, próbując nadać mu jakąś strukturę, ale w trakcie po prostu rozmowa sama zmierza w różnych kierunkach. I z tego się akurat cieszę :).
Co do samego TDD i procesu nauki: w 100% się z Tobą zgadzam. Na początku TRZEBA robić tak jak ktoś KAŻE (ktoś: uncle bob właśnie) a dopiero potem konstruować własne praktyki.
Harry,
No to git, cieszę się :). Musi być coraz lepiej z każdym odcinkiem bo inaczej byłoby bez sensu.
Jak będziesz potrzebował do kogoś powiedzieć te rzeczy z ogłoszeniami to zadzwoń na Skype :).
Wyszło bardzo dobrze, ciekawe się słucha. Tematy jak do tej pory są spoko i tym razem udało się być ekspertem również :). Chcemy chleba i podcastów!
Teraz nie wiem co myśleć o UT i jak najlepiej podejść do tematu w moich projektach. Trzeba przemyśleć temat na spokojnie przy piwku :)
Teraz trochę wazeliny. Temat z UT to strzał w dychę. Osobiście od pewnego czasu dochodziłem do tych samych wniosków co Adam, co nie dawało mi spokoju czy idę w dobrym kierunku. Teraz wiem, że nie jestem osamotniony :)
Dobry podcast. Porcja materiału, która według mnie jest godna polecenia devom, managerom i firmom przygotowującym oferty praktyk letnich ;). Swoją drogą świetne anegdoty i przykłady “z życia” przedstawione w podcaście przez Was obu :).
Co do strony technicznej: Zgadzam się z poprzednikami – na początku trochę mechanicznie. Mimo wszystko ogromny szacun!
Updated :)
http://groopmark.com/link/details/181/devtalk—programistyczny-glos-w-twoim-domu
Super inicjatywa z tym podcastem. Z odcinka na odcinek coraz lepiej, do 2 i 3 odcinka poświęciłeś chyba więcej czasu na przygotowania, niż do 1-szego i to słychać. Moja sugestia odnośnie tego co można by zmienić na lepsze niestety nie będzie oryginalna. Część poświęcona ogłoszeniom to lekka masakra, jeśli chodzi o szybkość wypowiadania słów… chociaż obcokrajowiec posługujący się językiem polskim w stopniu ograniczonym byłby Ci na pewno wdzięczny za to tempo :D
Fajna inicjatywa :) Mam nadzieję, że starczy czasu i zapału i powstanie jeszcze sporo odcinków :)
@Tomek, @all,
Następnym razem chyba po prostu walnę browara przed nagrywaniem części niebędącej rozmową z gościem :)
dla mnie bomba. podoba mi sie przede wszystkim to, ze grupa docelowa tych audycji to jednak ci bardziej zaawansowani i mozna uzyskac informacj ktorych gdzie indziej w internetach brak. jedyna prosba: postarajcie sie uzywac wiecej polskiej nomenklatury
Jest jakiś powód, dla którego nie wrzucasz nagrań na YouTube?
Osobiście lubię słuchać nagrać/prezentacji w … pracy :) a czasami mam problem ze streamem. Przez co muszę wcześniej ściągnąć, a wygoda spada. Wiem, że jest sporo osób takich jak ja więc możesz tracić słuchaczy przez to.
Chyba nie będę oryginalny, ale:
Ogólnie patrząc, rzeczywiście widać postęp w jakości. Duży big up za to.
Natomiast rozbijając na ‘część organizacyjną’ i ‘rozmowę’, to ta druga wypada dużo lepiej.
Długo szukałem odpowiedniego słowa, ale wydaje mi się, że najlepiej napisać, że część ogłoszeń jest ‘przekombinowana’ ?
A rozmowy fajnie się słucha, całość jest dobrze poprowadzona, nie ma przestojów, tematy płynnie przechodzą. Dobra robota
Czekam na kolejny odcinek i kolejne postępy ;)
Rozmowa rozpoczęła się trochę kontrowersyjnym stwierdzeniem Adama, gdzie nie namawiał wszystkich do pisania testów jednotkowych za wszelką cenę, a jak już je pisać te testy, to nie koniecznie testować jak najmniejsze elementy kodu, a raczej większe części systemu. Maciej przytakiwałeś w wielu miejscach ale przy okazji dzielnie broniłeś swojego podejścia, w którym piszesz bardzo dużo testów.
Ja w wypowiedzi Adama dostrzegłem analogię do swojej ostatniej sytuacji w pracy. Dopisywałem nową funkcjonalność do systemu kolejkującego połączenia w call center, podczas której testy jednostkowe bardzo ułatwiły mi pracę.
Klient zamówił przydzielanie połączeń do konsultantów w taki sposób, aby osoby wdzwaniające się ponownie na infolinie były łączone z tym samym konsultantem, z którym rozmawiali poprzednio, zachowując przy tym kolejkowanie na starych zasadach. Czyli (w dużym skrócie) trzeba było zrobić historię połączeń i na jej podstawie przydzielać połączenia.
Testowanie kolejkowania połączeń w tym systemie wiązało się z uruchomieniem bardzo dużej kobyły co zabierało bardzo dużo czasu. Po każdej zmianie kodu, gdy chciałem przetestrować to co napisałem musiałem czekać trzy, cztery minuty, aż wsszystkie elementy systemu wstaną. Testowanie wymagało uruchomienia aplikacji serwerowej, która nawiązywała połączenie z centralą telekomunikacyjną, oraz uruchomienia aplikacji klienckiej, w której dany konsultant się loguje na dany numer telefonu, po czym należało wykręcać kolejne połączenia na telefonach stacjonarnych, i w efekcie w tej aplikacji klienckiej należało oglądać czy kształt kolejki jest zgodny z oczekiwanym. Masakra.
Mechanizm zarządzania kolejką znajduje się w części serwerowej więc, każda zmiana kodu wiązała z się odpaleniem wszystkiego po kolei od nowa. Zanim ta cała kobyła wystartowała, można było zapomnieć co się chciało przetestować.
Tutaj z pomocą przyszły mi właśnie testy jednostkowe. Kod odpowiedzialny za zbieranie historii rozmów, oraz rozdzielanie połączeń do konkretnych konsultantów odpalałem w testach jednostkowych. Przyznam się, że nie za każdym razem najpierw pisałem test a potem kod, ale się starałem. Czasami pisałem test już po napisaniu kodu, ale nie przez to, że testy są fajne, tylko po to, żeby nie musieć odpalać tej całej kobyły i tracić czas. Odpalałem sobie tylko wybrane fragmenty kodu. O tym, które fragmenty kodu mi się uruchamiały, decydowałem właśnie w testach. Czasami pisałem dany test aby przedebagować sobie dany fragment systemu.
Dzięki testom jednostkowym mogłem uruchamiać precyzyjnie wyznaczone kawałki kodu i nie koniecznie były to małe kawałki. Nie musiałem dzwonić z tych telefonów stacjonarnych aby sprawdzić czy to co napisałem działa tak jak chciałem.
Uogulniając, testy jednostkowe są doskonałym narzędziem do przyspieszenia wytwarzania kodu a nie do spowolnienia – jak to często krąży gdzie nie gdzie opinia. Czasami słyszę opinię, że nie mamy czasu na pisanie testów jednoskowych. Będzie luźniejszy okres to zastanowimy się nad pisaniem tych testów. Nic bardziej niedorzecznego. Testy jednostkowe mają pomagać a nie przeszkadzać pisać kod. Jeśli przeszkadzają to oznacza, że trzeba jeszcze trochę się pouczyć na ten temat. W moim przypadku pomogły już podczas pisania. W innych przypadkach umiejętne pisanie testów, może być inwestycją na przyszłość która się zwróci w nadmiarze.
Muszę się przyznać, że nie uchroniłem się przed bugiem, który spłyną z produkcji po trzech tygodniach po wdrożeniu. Nie będę tutaj pisał co to był za bug, bo nikt i tak tego by nie doczytał do końca (o ile jeszcze tu czyta ktoś to).
Na własnych kościach potwierdziła mi się kolejna prawidłowość, o której też mówiliście. Pisanie testu nie uchroni nas przed błędami.
P.S. NCruncha, używałem do póki mi się okres darmowy nie skończył i używałbym dalej, bo to dobre narzędzie jest.
Podoba mi si cykl spotkań. Porównanie braku testów do auta bez hamulców dobrze działa na wyobraźnię.
Moje zastrzeżenia: powinniście bardziej uważać na język – mogą Was słuchać młodzi adepci programowania.
Czepiam się:
– słychać łączenie ścieżek
– ktoś brzęka i to przeszakadza (chyba Adam)
– brak linków do dyskusji “TDD is dead”
Plusy:
– nie czepiałbym się technicznych rzeczy, gdyby merytorycznie nie było superowo. Nie potrafię się do niczego w tym względzie przyczepić :)
– muzyka na końcu
Czacha dymi :D Przyjemnie się słucha. Mimo, że to 40 min, nie zauważyłem kiedy minęło i w międzyczasie prasowanie zrobione. Żona szczęśliwa ja też piękny przykład win-win ;)
Wydaje mi się że w tle słyszałem jak ktoś bawi się monetami i dźwięki rozkładanych naczyń chyba talerzy. Proszę o potwierdzenie bo nie wiem czy muszę udać się do specjalisty.
Odnośnie TDD. Wszystko jest trucizną decyduję tylko dawka. Co do samego DHH to gość jak dla mnie mówi w wielu miejscach z sensem np. RailsConf 2014 (https://www.youtube.com/watch?v=9LfmrkyP81M).
Na koniec cytacik:
‘TDD is for scared people is for pussys’ Erik Meijer “One Hacker Way – Erik Meijer” http://vimeo.com/110554082
:P
WHITEBEAR,
Nie bardzo łapię w czym jest problem, który rozwiązałby YouTube. Można ściągnąć mp3, można streamować bezpośrednio ze strony, można słuchać z aplikacji “podcastowych”. Czyli są 3 opcje, podczas gdy w youtube: tyko jedna.
W sprawach techniczno/organizacyjnych (hosting, player na stronie, generowanie feeda…) wzorowałem się trochę na Hanselminutes i DotNetRocks. Ich nie ma na YouTube, YouTube nie czyta feeda tylko trzeba by było ręcznie wgrywać tam każdy odcinek, no i… youtube jest to video, a nie audio :).
Olo,
Prawda, mi też ta analogia bardzo się podoba.
Co do języka – bez przesady, “dupa” czy coś na podobnym poziomie “wulgaryzmu” jeszcze z nikogo hultaja nie zrobiła. Nie ma i nie będzie rzucania mięsem, ale też nie chcę przeginać w drugą stronę, tym bardziej że na co dzień w wypowiedziach bliżej mi do rynsztoka niż do świątyni.
TEOVINCENT,
Też pisałem CallCenter, i to nawet 2x! :) Na FreeSWITCHu.
Za pierwszym razem testy mi głównie przeszkadzały. Za drugim już – odwrotnie.
Artur,
No to cool :). Łączenie ścieżek, jakieś brzęknięcia itd to kwestie czysto techniczne i moim zdaniem są do zaakceptowania. Nie nagrywamy albumu z piosenkami więc jakościowo (szczególnie od tego odcinka, kiedy nie ja już to montuję) jest i tak lepiej niż początkowo zakładałem.
Ja pociągnę to o czym napisał Artur – temat TDD is dead został potraktowany bardzo po macoszemu. Rozumiem, że brakowało czasu, ale poza tym że niewiele zdążyliście o tym powiedzieć, to nie wiem do kogo miał być skierowany ten fragment podcastu. Jeżeli do wyjadaczy, którzy kojarzą tekst i cała dyskusję, to za mało się w niego wgryźliście (co zrozumiałe bo było za mało czasu). Jeżeli do programistów początkujących i/lub tych których cała dyskusja ominęła to jest kilka błędów:
– brak pełnego nazwiska osoby, która wysunęła tezę TDD is dead (jasne ja też nie powtórzę z pamięci, ale skoro Maćku masz w planach poruszyć ten temat to trzeba się przygotować)
– nawet jednego zdania o co chodziło w tej całej dyskusji, jakie były podstawowe wnioski – wyszliście z założenia że każdy tę dyskusję zna. Ja mimo to że ją śledziłem, to nie pamiętałem wszystkiego (shitstorm był tak duży że już nie pamiętałem kto co powiedział / napisał :P)
Link do postu: http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
I ciekawa dyskusja pomiędzy Martinem Fowlerem, Davidem Heinemeier Hansoonem i Kentem Beckiem m.in: http://martinfowler.com/articles/is-tdd-dead/
To jest ogólny problem przy podcastach developerskich (i też przy blogach). Do kogo ma być skierowany DevTalk? Do wyjadaczy, którzy mają swoje praktyki, wyrobione zdanie i z niejednego pieca chleb jedli? Wtedy ryzykujesz, że za parę odcinków zaawansowani programiści się wykruszą ze słuchaczy, bo nie będzie tu dla nich nic nowego / odkrywczego.
Jeżeli podcast ma być dla developerów mniej doświadczonych, to trzeba zadbać o to, żeby ich nie “alienować” – przy dyskusji dwóch osób o bardzo dużej wiedzy, tak jak było w tym odcinku, łatwo jest się zgubić, nie nadążyć, przez co jakieś osoby mogą się zniechęcić. Przez większość odcinka dobrze to prowadziłeś (tak mi się przynajmniej wydaje, że nawet ktoś nieobeznany w temacie TDD nadążał, a jednocześnie nie było to nudne dla osób obeznanych z TDD), ale przy “TDD is dead” trochę nie wyszło.
Mam nadzieję, że pociągnięcie ten temat dalej w którymś z przyszłych odcinków
I czy jestem jedynym, któremu “muzyka” na początku podcastu się nie podoba? :) Te różne dźwięki brzmią jak wyrwane z jakiegoś psychodelicznego filmu ;)
Aha i popieram Olo: sam klnę (a da się programować bez tego? ;) ) a mimo to uważałbym z takimi stwierdzeniami jak “o kant d…. potłuc” itp. Niedawno się spotkałem z ciekawym stwierdzeniem o nadużywaniu “F Bombs” w książkach czy filmach: jeżeli ich się nie używa, to raczej nikogo ze słuchaczy / czytaczy / oglądaczy nie stracimy (no chyba że to film mafijny i spodziewamy się takiego języka, ale z drugiej strony w Braking Bad nie pada ani razu słowo na “F”). W drugą stronę – jak używa się takich zwrotów, prawdopodobnie kogoś to będzie raziło i nie wróci do słuchania / oglądania / czytania.
A podobno też łatwo w iTunes dzięki temu zarobić taga “Explicit”, ale wtedy jest przypięty do całego podcastu, a nie do poszczególnego odcinka – ale nie jestem w stanie sprawdzić czy tak jest rzeczywiście. Usłyszałem to w jednym z podcastów.
Czytając te wszystkie komentarze, czuję się jak bym jadł “schabowy, ziemniaki i kapustę zasmarzaną” bez schabowego.
W komentarzach oczekiwałbym mięsa, czyli więcej dzielenia się własnymi doświadczeniami i opiniami na temat testowania jednostkowego. Na tą chwilę, z komentarzy mogę się dużo dowiedzieć jak robić, lub jak nie robić podcasta, zamiast skonfrontować wypowiedzi z nagrania z opiniami innych devów.
Dlaczego to porównałem do “chabowego, ziemniaków i kapusty zasmażanej”? Bo to jedno z najlepszych dań jakie kiedykolwiek jadłem i prawdopodobnie lepszego nie uda mi się zjeść (podobną opinię mam na temat tego devtalka).
Ziemniakami są wszystkie wasze komentarze mówiące o tym, czy wam się podoba jakość nagrań, czy muzyczka jest fajna, czy może ton i intonacja prowadzącego jest nieprawidłowa. Ziemniaki w tym daniu są tak oczywistym elementem, że nie zastanawiamy się zbytnio nad nimi. Dopiero jak by ich zabrakło to od razu zostałoby to zauważone. Ziemniaki w tym daniu, więc, są bardzo ważne, bo informacja zwrotna bardzo się przydaję.
Smaczna kapusta zasmażana, w tym daniu to odpowiedzi Macieja. Strara się każdemu odpowiedzieć i to jest fajne. Powoduje, że danie smakuje idealnie.
Schabowy w tym daniu to wypodziewi na temat merytoryczny, których tutaj brakuje. A szkoda, bo możnaby się wymienić własnymi przemyśleniami na temat tego co słuchamy, porównać je i wyciągnąć swoje, własne, nowe wnioski.
Więc, niby pojeść sobie można, bo ziemniakami się zapchamy, przegryziemy smaczną kapustą ale mięsa brak. Na dłuższą metę, tak jeść się nie da.
Sam pomysł na podcast jak i wykonanie zacne. Jak na razie merytorycznie najbardziej podobał mi się odcinek z Gutkiem, pozwolił on spojrzec z szerszej perspektywy na romans c# + js, liczę na kolejną część :). Zgadzam się z przedkomentatorami co do ogłoszeń, są strasznie sztywne, ewidentnie potrzeba Ci drugiej osoby do której byś kierował wypowiedź. Mam jeszcze propozycję, aby pod każdym podcastem umieszczać linki do wymienionych w trakcie rozmowy bibliotek, artykułów itd, żeby nie trzeba było po powrocie do domu szukac w podcascie miejsca gdzie były one podawane :) Np. wszystkie biblioteki z pierwszego odcinka lub wypowiedzi DHH nt TDD w trzecim. Czyli po prostu ‘Links from the Show’, jak to wrzucają Np. w .net rocka.
Trochę mało konkretniejszych rzeczy jak dla mnie. Zabrakło wzmianek o mock’ach, refactoringu, a czasami wręcz naprawy złego kodu właśnie dzięki TDD. Nikt nie wspomniał również o DI, które niekiedy jest wręcz koniecznością aby napisać test, co z kolei pozwala na nieco mniej “tightly coupled methods”.
Wspomniany NCrunch (czy też Infinitest dla Javy) sprawiają wręcz, że część wspomnianych problemów odpada. Przede wszystkim dzięki widocznemu code coverage w czasie rzeczywistym, bardzo łatwo można rozbijać nazbyt duże metody na mniejsze i od razu widzieć czy coś się popsuło. Można wyciągać przetestowane już fragmenty z metod
Wielokrotnie wykryłem błędy w tzw. legacy code, właśnie dzięki temu, że napisałem test już do czegoś co niby działało (nazwa metody i komentarz wskazywały jak powinna działać, napisałem test weryfikacyjny i bingo – był błąd na produkcji, który nie został wcześniej wykryty).
W samym podcaście dosyć często autorzy zmieniali kontekst – warto byłoby jasno wskazywać czy mowa jest o BDD, TDD czy jeszcze czymś innym – rozumiem kilku godzinne pisanie testu pod BDD, ale jeżeli to ma miejsce w TDD to raczej trzeba refactorować metodę.
A skoro już mowa o BDD to gdzie podział się Spec Flow oraz gherkin, który może być właśnie zrozumiany przez owego krwiożerczego szefa i jego klienta? Przecież możliwość zdefiniowania wymagań biznesowych we wspólnym języku, a potem dość łatwe przeniesienie tego na grunt testów to jak dla mnie kluczowa sprawa.
Zgadzam się również, że jest sens robić podział na testy behawioralne, funkcjonalne i jednostkowe. Te ostatnie doskonale działają z NCrunchem i mogą odbijać się od Gated Check-in, te pierwsze chodzą sobie spokojnie nocą i raportują za dnia.
Testy ponadto idą jeszcze dalej. Mój ulubiony przykład, o którym mówił Neal Ford – testy powinny weryfikować wszystko co może pójść źle. Wyobraź sobie że ktoś do aplikacji sklepowej wrzuca obrazek “kup.png”, który jest pusty – sprzedaż leci na łeb na szyję. To już oczywiście głębsze zagadnienie z zakresu wykrywania anomalii w systemie, ale można pomyśleć o czymś prostszym – zmiana css lub html. Bez dobrych testów e2e zapuszczanych automatycznie na różnych przeglądarkach, strata może być bolesna zanim odkryjemy, że w konkretnej wersji przeglądarki rozjechał się przycisk.
Temat zatem jest spory, myślę że na więcej niż jeden podcast.
Dzięki za wszystkie komentarze, zarówno te “merytoryczne” jak i te odnoszące się do technikaliów podcasta.
Oczywiście nie da się pogadać w “głębokim” stopniu i o roli testów, i o TDD (o tym mam zaplanowany osobny odcinek), i o BDD (o tym też), i o mockach (o tym też) i jeszcze o tym czy “tdd is dead” (o tym nie) w ciągu 30 minut. Raczej nie spodziewajcie się, że którykolwiek z odcinków DevTalka rozprawi się z jakimś tematem od początku do końca na takim poziomie jak robią to książki czy artykuły. To zawsze będzie trochę “ślizganie się po powierzchni”, przyjemna lekka rozmowa mająca na celu miłe spędzenie pół godziny.
Cześć wszystkim, z tej strony “ekspert” niniejszego odcinka.
Ponieważ wiele osób tutaj poruszyło ciekawe kwestie, postaram się je skomentować po kolei i być może dolać trochę oliwy do ognia. Raczej nie będę dyskutował o sprawach technicznych nagrania, bo tu już chyba wszystko zostało powiedziane (i też zwyczajnie się nie znam :)
Na początek kilka ogłoszeń ogólnych:
– Kajam się za stukanie na nagraniu, to szklanka wody i pobliski stolik. Strasznie zasycha w gardle w trakcie rozmowy. Nie miałem pojęcia że aż tak się załapie. Przy następnej okazji założę tą śmieszną czapeczkę z piciem i słomką :)
– Wszystkie opinie są moje, tylko moje i nikt nie musi się z nimi zgadzać – a nawet nie powinien. “Think for yourself. Question authority”, że zacytuję wieszcza. A niektóre opinie miewam skrajne.
– No i najważniejsze, wielkie dzięki dla Maćka za zaproszenie i za rozmowę – to była przyjemność, mam nadzieję, że jeszcze kiedyś uda nam się ją powtórzyć. Nawet jeżeli tylko offline
No to od końca:
@Marcin:
Testy to baaaardzo szeroki temat, i te pół godziny pewnie nawet nie wystarczyłoby na wymienienie wszystkich terminów jakie wiążą się z testami. Mam nadzieję, że Maciek będzie sukcesywnie rozwijał temat.
Super, że poruszyłeś wiele ciekawych punktów, na które nie miałem okazji ponarzekać z Maćkiem :)
O ile w ogólności zgadzam się z wieloma Twoimi punktami, to nie do końca wiem czy mogę z takim entuzjazmem skakać w Dependency Injection. To potężna technika która jest łatwa do nadużycia, co w ekstremalnym powoduje dziesiątki (setki?) pozornie niezależnych klas. Mamy wtedy co prawda “loosely coupled”, ale za to tworzymy sieć “ukrytych” zależności – jedna klasa wykorzystuje kilka zależności z których każda ma kilka swoich, itd. Oczywiście możemy je wtedy przetestować w izolacji, ale musimy wszystkie zależności mockować – co zwykle oznacza dużo większy test setup i co gorsza nasza logika przecieka do szarej strefy “pomiędzy” naszymi klasami i wszystkich czasem bardzo subtelnych zależności.
Na tym polu jestem zdecydowanie po stronie “cohesive” – nie mam nic przeciwko testowaniu całego bloku (komponentu) złożonego z kilku klas, jeżeli przynależą blisko siebie, nie są używane nigdzie indziej i mogę odciąć zewnętrzne zależności typu baza danych. Takie testy “outside-in”.
Jeżeli już jesteśmy przy rodzajach testów to jestem fanem BDD – chociaż nigdy nie widziałem nikogo z biznesu kto pisałby historyjki SpecFlow. Ale stanowią one bardzo dobry środek komunikacji i niejako kontrakt między developerami a product ownerem.
Nie wiem czy dobrze cię zrozumiałem w ostatnim punkcie, ale nie chciałbym pisać testów “explicit” na wszystko co może pójść źle w aplikacji. Jest tego zwykle zbyt dużo i już identyfikacja wymaga zwykle osobnego człowieka – explorative qa. Zaimplemetowanie, testowanie i potem utrzymywanie pochłania relatywnie wiele zasobów i w tym czasie można zrobić kilka innych bardziej pożytecznych rzeczy
Podążając za twoim przykładem, jeżeli ktoś nie sprawdził jaki obrazek wrzuca, to w 9 przypadkach na 10 to zysk w postaci nie-spadku sprzedaży jest dużo niższy, niż łączny koszt setki takich ficzerów. Ten 1 na 10 to np. Gmail sprawdzający czy dodałeś załącznik jeżeli w tekście napisałeś “Uprzejmie załączam” :)
@Teovincent
Boska analogia :) Aż się głodny zrobiłem. Zjadłbym sobie schabowego z ziemiaczkami …
@Marcin Krupiński
Świetne uwagi, ciężko jest dyskusję TDD-is-dead przedstawić tak, żeby zainteresowała zarówno
nowicjuszy jak i bardziej doświadczonych, a z racji tego że obaj z Maćkiem siedzimy w tym
głęboko, przeskoczyliśmy od razu do wniosków.
No i kajam się za brak profesjonalizmu. Przed nagraniem próbowałem się nauczyć nazwiska pana
Davida Heinemeiera Hanssona, ale jest to spore wyzwanie (spróbuj powiedzieć to szybko trzy razy
:).
Ale masz rację wyszło trochę po wiejsku.
@ Marcin Krupiński, Marcin Nowacki, TDD-Is-Dead
Co do samej dyskusji, DHH to mądry gość w sumie miał rację – z wyjątkiem tego fragmentu kiedy się mylił nazywając wszystkie złe rzeczy jako TDD. Wszystkie “Test induced damage” jakie opisał są powszechne, jeżeli podchodzi się do testów od strony praktyk zamiast od strony idei (principles).
Co zresztą jest prawdziwe w bardzo wielu różnych przypadkach (ktoś wspomni Agile? :)
Zauważyłem również ciekawą korelację, między takim takim rozumieniem TDD a ilustrowaniem go za pomocą Coding Kata – ale ten ciekawy temat zostawię na następną okazję.
@Teovincent o call center
Również mam zbliżone doświadczenia, chociaż nie call center a system IVR – “Naciśnij 1 aby usłyszeń o naszych promocjach … ” itd. Wiele rzeczy udało nam się objąć testami “jednostkowymi”, bez potrzeby deploya i odpalania serwera. Było ciekawie, ponieważ każdy poziom menu był naturalnym kandydatem na “jednostkę” w naszych testach. Mogliśmy wziąć dany punkt systemu, symulować wciskanie klawiszy poprzez eventy w kodzie i weryfikować czy następny punkt na liście jest taki jak powinien. Taki mocking framework na VB.NET :)
Mieliśmy również testy na już zdeployowanym systemie – wdzwaniał się na maszynę, po czym osobny proces sprawdzał czy odpalane są właściwe pliki głosowe. O dziwno, nawet jakoś to działało.
W pewnym momencie chcieliśmy to zastąpić prototypem który symulował telefon po czym próbował robić voice recognition aby sprawdzić czy IVR mówi to co powinien, ale mieliśmy problemy ze stabilnością i powtarzalnością wyników. Ale przynajmniej było trochę zabawy :)
@ Adam Kosiński
Dzięki za odp. Mam potwierdzenie, że podobne tematy, gdzieś tam ktoś, w podobny też sposób rozgryza.
Kiedyś wystawiłem na GitHub mały projekt z wyciągniętym “wzorcem” na jakim się opieramy przy budowaniu drzew IVR. Tutaj jest, kilka testów, które wnioskując po twojej wypowiedzi, koncepcyjnie są identyczne z Twoimi:
https://github.com/TeoVincent/Root-Nodes-Workflow-Pattern/blob/master/RootAndNodesPattern/RootAndNodesPattern.UnitTests/WorkflowTest.cs
Zgadzam się z Wami, że w wielu przypadkach nawet do legacy code warto dopisywać testy.
Przykład z życia: W systemie miałem (napisaną przez kogoś innego) metodę która umożliwiała wyznaczenie ilości dostępnych usług dla klienta w zależności od daty startu jego uprawnień, rodzaju okresu (rok, kwartał, miesiąc), rodzaj limitu (czy traktować początek roku jako start, czy datę startu uprawnień) oraz ile już usług miał wykonanych.
Dostałem do naprawienia błąd w tej metodzie bo źle był wyliczany numer kwartału i przez to określana ilość usług.
W tym przypadku dużo prościej było napisać test który sprawdza przypadki wszystkich czterech kwartałów niż próbować na kartce przeliczać czy muszę numer miesiąca podzielić przez 3, czy przez 4; czy numer miesiąca zwiększyć o 1 i dopiero podzielić.
Przede mną ktoś inny naprawiał tą metodę i właśnie zmienił z dzielenia przez 3 na dzielenie przez 4 (albo odwrotnie) i jego konkretny przypadek naprawił, a za to zepsuł inne.
Czasem ciężko testować coś co nie jest przystosowane do testowania, ale w wielu przypadkach, aż się prosi o testy jednostkowe.
Jej! Widzę, że robi się coraz ciekawiej i bardzo się cieszę, że mogłem przyłożyć swoją małą cegiełkę do tak zacnego projektu.
This is crazy! ;)
Hej,
Super podcast! Dużo ciekawych uwag/sugestii/przemyśleń.
+1 za intro :) Nie mogę się doczekać co wymyślisz za tydzień :D
Co do testów i TDD to ciekawi mnie czy zgadzacie się ze stwierdzeniem, że zanim zacznie się używać TDD, należy się dobrze nauczyć pisać testy. Tzn. zrobić kilka projektów, gdzie testy pisze się PO implementacji i kiedy już mamy wprawę to wtedy próbujemy TDD. Inaczej będzie frustracja i myśli typu, że to jest bez sensu.
Co do kwestii technicznej to tak jak kilka osób wspomniało fajnie byłoby mieć linki do źródeł pod podcastem (tak jak Hanselminutes). Przydały by się też jakieś rekomendacje tutoriali/książek. Jest masa tego w internetach, a rekomendacja od ekspertów jest zawsze pomocna.
Poziom merytoryczny: 5/5.
Pozdrawiam i czekam na następny odcinek!
Jakub
Uwaga uwaga, NCruncha otrzymuje TEOVINCENT!
Proszę o kontakt to pociągniemy temat dalej. Gratuluję i dzięki za tak obszerne komentarze!
Dziękuję zresztą wszystkim, mam nadzieję że gorące dyskuje będą się pojawiać pod wszystkimi postami, nie tylko wtedy kiedy będę oferował jakieś nagrody ;).
Co do linków do materiałów omawianych w poście: pod każdym odcinkiem je wrzucałem, tutaj po prostu nie mówiliśmy o żadnych konkretnych “rzeczach” które można podlinkować:). Oprócz dyskusji między DHH a resztą – faktycznie powiniem to wstawić.
Polecane przeze mnie materiały do nauki o testach można zobaczyć tutaj: http://www.maciejaniserowicz.com/2013/04/22/testy-jednostkowe-materialy-do-nauki/ .
Dzięki za wyróżnienie. Na pewno się nie zmarnuje ta licencja w moich rękach.
P.S. DavTalk ma to do siebie, że po wysłuchaniu nagrania, czuję się, że jest się zaproszony do włączenia się w rozmowę.
http://teo-vincent.blogspot.com/2014/12/ncrunch-mam-go-wygraem-w-konkursie-na.html