Niech Wam testy przejdą :)

Ostatnio trochę Was zaniedbałem za co serdecznie przepraszam i obiecuję, że w nadchodzącym roku postaram się nadrobić dwumiesięczny brak aktywności na blogu :) To tyle w kwestii usprawiedliwiania się, w końcu kończy się rok i nie ma co płakać nad tym, co nie wyszło w stu procentach tak jak byśmy chcieli. Natomiast tym, co wyszło dobrze albo nawet lepiej niż zakładaliśmy również trzeba przestać się zachwycać i zrobić miejsca na kolejne sukcesy :)

Dzisiaj krótko i w klimacie TDD - Niech za rok, po odpaleniu, poniższe testy Wam przejdą :)

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ć :)

Test ma testować, nie powielać kod metody.

czy aby oczywiste jest to wszystko?

Niby jasne, że właśnie tak to powinno wyglądać, ale naprawdę często (dobra, dla ścisłości - częściej niżbym chciał:) zdarza mi się oglądać testy, w których ciele mam dokładną kopię kodu, który znajduje się wewnątrz metody testowanej.
Zdaję sobie sprawę, że w przypadku niektórych rzeczy dużo wygodniej jest wykonać kilka instrukcji niż zastanowić się jaki może być wynik. Najczęściej, takie mam przeświadczenie, programiści decydują się na kopiowanie kodu z metody po to, aby się przypadkiem nie pomylić i żeby oczekiwany wynik był na pewno dobry.

I w tym miejscu pragnę wrzucić delikatne, ale jakże wymowne - WTF?!

Mój kod jest świetny!

Testowanie to naprawdę świetna sprawa. Pokazuje, czy wszystko działa:)
Tylko, że niestety nie pokazuje. Jedynie dostarcza nam informacji, że nie udało nam się znaleźć błędu, a to jest naprawdę istotna różnica.