Testy dla ludzi

Post zaczniemy od części multimedialnej - 29.03 na łódzkim JUGu miała miejsce prezentacja wykonana przez skromnego spikera w mojej jeszcze skromniejszej osobie. Głównym tematem były testy mutacyjne, o których wspomnę kiedy indziej. Dzisiaj będzie za to trochę herezji, ale najpierw seans.

Po co są zasady...

W niemal każdej książce, na niemal każdym blogu i chyba w każdym artykule poświęconym inżynierii obiektowej pojawia się zasada znana jako DRY - "Don't Repeat Yourself". Zasada jest dobra - nawet bardzo dobra - podobnie jak zasada jazdy prawym pasem. Przestrzeganie jej będzie ratować nam życie dopóki nie wyjedziemy zarabiać w Anglii na zmywaku - wtedy przestrzeganie jej może nas zabić...

Jedziemy na razie prawym pasem. Poniższy obrazek przypomni klasyczne zyski zastosowania zasady DRY. Wyobraźmy sobie, że to kawałek kodu sterującego robotem przemysłowym. Powyżej sexownej czerwonej kreski mamy powtarzający się kod, który nie wiele nam mówi. Stosujemy zasadę DRY - i BUM - poniżej czerwonej kreseczki widzimy, że tzw. "ektrakcja metody" nie dość, że usunęła nam powtórzenie to jeszcze wprowadziła aspekt samo-dokumentacji kodu.

Teraz czas zjechać na pas przeciwległy.

Jak najlepiej czytać dokumentację ?

Jak wyglądałaby idealna dokumentacja według zasady DRY? Poniżej chyba nic się nie powtarza a poszczególne koncepcje są wyciągnięte do osobnych punktów i paragrafów.

Teraz następuje krytyczny moment, gdyż aby zrozumieć konsekwencje takiego zapisu trzeba wysilić swoją wyobraźnie i zdolności empatyczne. W chwili obecnej czytelnik być może siedzi wygodnie w fotelu popijając kawę lub browara i pełen relaksu zerka na załączone fotografie zastanawiając się "co w tym takiego trudnego?"

Jak to mawiają trenerzy NLP : "czy masz na tyle odwagi aby wyobrazić sobie, że siedzisz po 6 godzinnym maratonie kodowania ( w firmach nastawionych na 'napierdalanie' gdzie przerwa obiadowa jest około godziny siedemnastej należy liczbę 6 zamienić na 13) , gonią cię terminy, manager non stop rozprasza pytaniami na kiedy TO będzie, a w domu chyba zostawiłeś włączone żelazko ale na szczęście nie będzie pożaru bo chyba nie zakręciłeś też wody"

I teraz za przeproszeniem ku*wa należy rozpocząć dyskusję czy taki biedny programista będzie mieć siłę skakać pomiędzy klasami czy co gorsza analizować konfiguracje w xmlach aby rozwikłać zagadkę dlaczego dany test nie działa? (pytanie jest retoryczne). Czy wygodniej nam czytać dokumentację na screenie powyżej czy też może skłonimy się ku propozycji zamieszczonej poniżej.

Pisałem już w poście : wyczerpywanie się energii psychicznej , o tym jak nasza siła psychiczna męczy się od "noszenia" cięższych i bardziej skomplikowanych koncepcji. Dokumentację na drugim slajdzie na pewno łatwiej się czyta ale powstaje pytanie : co gdy chcemy ją zmienić. w przypadku dokumentacji papierowej nie jest wtedy trudno o pomyłkę czy przeoczenie ALE... W przypadku dokumentacji w postaci testów sytuacja się obraca moim zdaniem o 180 stopni gdyż jeśli testy są napisane poprawnie to każde miejsce, które nie nadążyło za aplikacją zgłosi błąd. I teraz oczywiście musimy się do każdego takiego fragmentu z osobna udać aby go naprawić i chyba jest to najlepsza metoda aby upewnić się, że nasza zmiana nie wprowadziła skutków ubocznych.

Oczywiście są pewne granice w ramach których powyższe rozumowanie jest poprawne. Te granicę są określone przez minimalny poziom abstrakcji potrzebny do zrozumienia instrukcji. Dla jasności poniższy przykład pokazuje już przekombinowaną dokumentację :

No to jak nie DRY to co?

Tak jak pisałem na początku tego wywodu - metody DRY nie należy (według mnie) traktować jako jakiegoś świętego prawa, którego nieprzestrzeganie sprowadzi na nas apokalipsę (21 grudnia 2012) ale jako zwykłą zasadę. Co ciekawe wystarczy rozejrzeć się dookoła aby zobaczyć jak łamanie tej zasady ratuje nam codziennie życie. Z tego co mi wiadomo nasz organizm przechowuje wzorzec DNA w wielu kopiach dzięki czemu jeden mały wirusik nie jest w stanie jednym pyknięciem zamienić nas w jednego wielkiego raka.

Jak więc może nazywać się zasada przeciwna do DRY?

Przykład z pracy

Na ostatnim już obrazku w tym odcinku widzimy przykład cennika. Generalnie działa to tak, że jak kupi się odpowiednią ilość geokodowań (geokodowanie to w skrócie zapytanie o miejsce na ziemi ) to skaczemy do następnego poziomu z niższymi cenami. Według zasady DRY powinniśmy mieć jeden zestaw danych i jeden mechanizm tworzenia tych danych. Jednakże ze względu na lepszy obrazek zastosujmy zasadę WET co zaowocuje stworzeniem trzech odrębnych zestawów danych. I teraz :

• Funkcjonalność szukania poziomów w ogóle nie potrzebuje żadnych cen. Wywalamy ceny i dzięki temu jak przestanie nam działać test to mamy mniej rzeczy do analizy
• Funkcjonalność liczenia kasy musi mieć wszelkie nieprzyjemne i brzegowe wartości coby w czasach kryzysu żaden miedziak się nie zawieruszył. Ten zestaw danych jest najbardziej rozbudowany.
• Tutaj mamy zestaw pośredni. Musimy się upewnić, że da się edytować co trzeba edytować ale już nie musimy 1500 różnych przypadków rozważać jak przy liczeniu kasy.

Podsumowanie

Oczywiście należy pamiętać, że wnioski którymi się tutaj dzielę, zostały zebrane na podstawie obserwacji ograniczonej grupy ludzi a czasem nawet wyłącznie na podstawie auto-psychoanalizy. Generalnie zauważyliśmy (ja i koledzy w pracy), że im więcej musimy się napocić przy czytaniu testu tym bardziej podświadomość traktuje go jako zbędny wydatek energetyczny. Coraz bardziej jestem przekonany, że pisanie testów należy zaklasyfikować do kategorii wyzwań "odroczonej gratyfikacji". Do tej pory wydawało mi się, że taki działający test stanowi gratyfikację sam w sobie jednakże ostatnie analizy skłaniają mnie do zakwestionowania tego wniosku - ale to już w innym odcinku.

Główny wniosek jest taki aby wszelkie niezbędne dane do zrozumienia testu były w zasięgu klasy testowej - żadne metody statyczne, żadne springi czy inne konfiguracje zewnętrzne mocków. Raz, że będzie łatwiej ten test zrozumieć, a dwa że można potem te lokalne ustawienia zoptymalizować aby test był jeszcze łatwiejszy do zrozumienia.

I tutaj mały wyjątek odnoszący się do akapitu mówiącego o minimalnym poziomie abstrakcji pisanej dokumentacji. (akapit nad pustynią). Generalnie rozwalanie hashmapy na drobne aby sprawdzić czy jakieś tam struktury mają inne struktury niekoniecznie sprzyja czytelności testu. Tutaj lepiej użyć Hamcresta albo FESTa. Doświadczenie wykazało, że jak już się dobrze napisze " maczera" to zazwyczaj nie trzeba już do niego zaglądać.