... a test, żeby testował jedną rzecz...

to zależy

Ostatnio mieliśmy w pracy prezentacją dotyczącą test double (swoją drogą polecam zainteresować się tematem i zacząć stosować wszelkiego rodzaju mocki itp., programista nawet nie zdaje sobie sprawy, jak wpływają one na jakość tworzonego kodu i czytelność testów).
Ale ja nie o tym (przynajmniej nie dzisiaj :).
Po prezentacji (i w jej trakcie) poruszyliśmy kilka tematów dotyczących testowania w ogóle i jednym z owych tematów było pytanie: czy jeden test powinien składać się z jedej asercji?
Jak to zazwyczaj bywa z takimi ideologicznymi pytaniami ludzie się podzielili na dwie grupy i zaczęliśmy dyskutować i wymieniać się poglądami. Nie muszę dodawać, że konkluzją było stwierdzenie "to zależy" :)

Tylko czy rzeczywiście "zależy"? A jeżeli tak, to od czego?

Ten kod mi się nie podoba...

somehow I don't like it

Rok, może dwa lata temu mieliśmy w firmie dyskusję na temat tego, co można zakwalifikować jako defect, a co nie powinno za takowy zostać uznane.
Nie mieliśmy na celu twardej definicji, ponieważ każdy z nas zdawał sobie sprawę, że granica jest dość cienka i subiektywna i najlepiej większą część "klarowania definicji" przerzucić na powolny proces jej naturalnego stabilizowania się w obrębie konkretnego zespołu.

Skupiliśmy się przede wszystkim na tym, co nie powinno zostać nazwane błędem. Pomysł na zrobienie takiego spotkania był wynikiem wielokrotnego pojawiania się "defectów", które nie informowały o niczym, nie dawały żadnych wskazówek i niekiedy nawet, po ich przeczytaniu nie było wiadomo co należy poprawić i co tak bardzo zirytowało osobę przeglądającą kod, że zdecydowała się na ten drastyczny krok.

Więcej nie znaczy wolniej

to już jest koniec

I dotarłem (i Wy również:) do końca tej serii wpisów.

Wielokrotnie, gdy czytałem któryś z nich, zaraz przed jego publikacją, dochodziłem do wniosku, że jeszcze przecież tyle rzeczy wypadałoby napisać, dodać i już prawie miałem to zrobić, ale... patrzyłem na jego długość i stwierdzałem, że jednak byłaby to przesada. Poza tym, nie gruntowne omówienie zagadnienia było moim zamierzeniem, a uzmysłowienie, w jak najbardziej skompresowanej formie, zalet opisywanych aktywności/procesów/technik oraz tego, że we wszystkim trzeba znać umiar. Czy mi się to udało? To pozostawiam już do Waszej oceny.

Zdaję sobie sprawę, że na każdy z poruszonych przeze mnie tematów możnaby (i już nieraz to robiono) napisać obszerne tomy i wiem również, że wiele rzeczy pozostało jeszcze do omówienia, więc jeżeli macie jakieś pytania albo chcielibyście więcej, to czekam na komentarze lub wiadomości na fan page'ach (na Google+ lub Facebooku).

Jeżeli chcecie niektóre (wszystkie?) z opisanych procesów zaimplementować u siebie w projekcie/pracy, ale nadal macie wątpliwości lub problemy z rozpoczęciem, to również czekam na Wasze pytania, może wspólnie uda nam się rozwiązać problem :)

Więcej nie znaczy wolniej cz. 8 - dokumentacja

Na wstępie cytat o tym, że dokumentacja jest jak seks

dokumentacja jest jak...

Dzisiaj zacznijmy od cytatu:

Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. - Dick Brandon

Osobiście uważam, że nic tak nie oddaje istoty tego, czym właściwie jest dokumentacja.

Więcej nie znaczy wolniej cz.7 - refaktoryzacja

ach refaktoryzacjo, a na cóż Ty mi?

Dzisiaj przyszła pora na jedną z przyjemniejszych aktywności opisywanych w ramach tej serii. Żeby jednak jakiś temat poruszyć, trzeba najpierw wiedzieć o czym będzie mowa, tak więc zacznijmy od początku, a na początku był kod (i jeszcze kilka innych produktów było wcześniej, ale na dzisiaj możemy założyć, że od kodu zaczynamy :).

Każdy z nas ma pewnie w sobie coś takiego, że chciałby aby jego kod był doskonały, pewnie większość z Was zaliczyła jakiś własny projekt, w którym setki razy dopieszczaliście isniejącą funkcjonalność, bo mimochodem wpadliście na pomysł, co tu zrobić, żeby działa/wyglądała lepiej, była czytelniejsza bądź przyjemniejsza dla oka. I tak w nieskończoność, aż pewnego dnia dochodzimy do wniosku, że już szkoda naszego czasu na pracę nad nim i trafia on gdzieś na dno szafy.

Pewnie równie wielu z Was zdaje sobie sprawę, że w projektach, które muszą ujrzeć światło dzienne i wyjść do użytkowników, takie zabiegi nie są możliwe i w pewnym momencie (zazwyczaj dość szybko) musimy powiedzieć stop i iść dalej.
Jednym zdaniem - projekty dzielimy na te idealne i te zrealizowane (niestety nie pamiętam autora cytatu) i osobiście zgadzam się z nim w zupełności i pomimo mojej lubości dobrych praktych, czytelnego kodu, itp., itd., kiedyś trzeba powiedzieć stop i ruszyć do przodu.

Więcej nie znaczy wolniej cz.6 - code review

Ech... i jeszcze to review kodu

Pora na kolejną "problematyczną" praktykę, a mianowicie na code review. Sama idea jest prosta do zrozumienia i polega ona na tym, że kod (jego forma, wygląd i sposób rozwiązania problemu) musi zostać zaakceptowany przez kogoś poza jego twórcą.
Tak naprawdę nie jest istotne czy używasz do tego celu specjalnie dedykowanych narzędzi, czy rozsyłacie patche ze zmianami, czy stosujesz do tego celu jeszcze inną technikę, ważne jest, aby na każdą linijkę, która chce "dostać się" na produkcję, popatrzył ktoś poza jej autorem. Dzięki temu nieustannie dbamy i poprawiamy jakość kodu, eliminujemy bugi implementacyjne, dodajemy, nie wzięte pod uwagę przez autora, test case'y itp.

Dobra, to skoro podstawowe informacje mamy za sobą, to pora przejść do jakichś konkretów :)

YAGNI + Test First

czy warto pisać testy przed implementacją?

Testowanie samo w sobie przynosi korzyści, zazwyczaj w dłuższej (oby:) perspektywie czasu, ale prędzej czy później jesteśmy w stanie dostrzec ich wartość i nieraz oddychamy z ulgą, gdy widzimy, że ludzie pracujący nad kodem przed nami, poświęcili trochę czasu na napisanie solidnych zestawów. Lecz o zaletach posiadania testów już pisałem ostatnio (tutaj i ciąg dalszy :).

I o ile z tym, że posiadanie testów przynosi korzyści i jest to jedna z tych rzeczy, którą wielu programistów chce praktykować nie kłóci się nikt, o tyle nie wszyscy widzą jakikolwiek sens w pisaniu testów przed implementacją. Że niby sprawia, że kod jest lepszy, że jeszcze raz myślimy o problemie, że patrzymy na niego od innej strony, itp., itd.
Problem z tymi wszystkimi stwierdzeniami jest taki, że to są jedynie oklepane zwroty, którymi karmią nas bardziej doświadczeni, mądrzejsi znawcy tematu, którzy powołują się na własne doświadczenie i którym powinniśmy zaufać. I ja wcale nie twierdzę, że nie mają racji, czy też nie neguję ich kompetencji, ale człowiek (a programista też człowiek :) woli uczyć się na własnych błędach. Przynajmniej do momentu, gdy nie zobaczy konkretnego przykładu, który pokazuje mu, że jednak jest tak, jak podpowiada starszy kolega.

Więcej nie znaczy wolniej cz.5 - testowanie po raz drugi

i jeszcze jeden i jeszcze raz...

Komentarze (krytyka :) pod wczorajszym wpisem zmotywowały mnie do powałkowania tematu testowania jeszcze przez moment.

Na wstępie jednak pragnę zaznaczyć, że i tym razem nie będzie ani jednej linijki kodu. Ta decyzja wynika bezpośrednio z tego, o czym wczoraj pisałem w komentarzu pod wpisem, a mianowicie z samego założenia dotyczącego serii - nie ma to być opis technik/procesów, czy też opis samej ich idei, chodzi mi raczej o przedstawienie argumentów, które mogą pomóc Wam (oczywiście jeżeli będziecie mieli na to ochotę) przekonać managera czy też właściciela produktu do zastosowania opisywanych aktywności w projekcie.

Muszę pokornie pochylić głowę i przyznać, że rzeczywiście we wczorajszym poście zabrakło przykładów z życia wziętych. Był zbiór uwag (swoją drogą całkiem słusznych :), które jednak poza opisem nie zawierał żadnych odniesień do rzeczywistości, w której przyszło nam się zmagać z klientami, managerami, czy też innymi opornymi przedstawicielami idei minimalizmu w odniesieniu do ilości procesów w trakcie tworzenia oprogramowania.

Więcej nie znaczy wolniej cz.4 - testowanie

no to co? może teścik?

A może jeszcze jeden? I kolejny? I jeszcze dziesięć następnych? I co?

No właśnie, i co? Obrońcy rzeczywistości, w której testów nie spotkasz nawet tam, gdzie mógłbyś (a wręcz chciałbyś) się ich spodziewać, nieustannie twierdzą, że z tą aktywnością nierozerwalnie wiążą się dwa podstawowe problemy:

• Ilość kodu, który testujemy niekiedy jest dużo większy niż ilość kodu testowanego (czyt. a można by przecież napisać tyle więcej nowej funkcjonalności)
• Testowanie nie daje gwarancji tego, że w produkcie nie ma bugów (czyt. jesteśmy tak pewni swojej aplikacji po je przetestowaniu, jak przed)

Oczywiście są to prawdy objawione, z którymi się nie da dyskutować.

Hmm... ale zawsze można spróbować :)

Czy to już czas?

Jakiś czas temu, po długim ślęczeniu nad bugiem zgłoszonym przez klienta, gdy udało mi się w końcu odkryć źródło problemu i otworzyłem plik z klasą, której metoda była odpowiedzialna za całe wyrządzone zło, popatrzyłem na kod i przed oczami stanął mi obraz dżungli, pełnej pnączy, drzew, zwierząt, insektów i wszystkiego, co tam jeszcze w takich dżunglach się znajduje. Niby dżungla jedna, ale jak wejść do środka, szczególnie bez przygotowania i dość obszernej wiedzy, co w niej można znaleźć, to aż przebiega zimny dreszcz po plecach.