DevTalk

Od niedawna Maciej Aniserowicz nagrywa około półgodzinne rozmowy, na tematy związane z wytwarzaniem oprogramowania. Polecam zajrzeć na stronę http://devtalk.pl/ i odsłuchać na próbę przynajmniej jeden z odcinków. Myślę, że większość z was wróci tam aby odsłuchiwać kolejne.

Zasady konkursu

W odcinku “03 – O TESTACH Z ADAMEM KOSIŃSKIM“, pojawił się konkurs, w którym można było wygrać licencję na NCrunch. Poniżej oryginał zasad konkursu ze strony:

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

NCrunch

NCrunch to bardzo fajne narzędzie wspierające pisanie testów jednostkowych. Kto jeszcze się z tym narzędziem nie spotkał, polecam aby wszedł na stronę http://www.ncrunch.net/ i obejrzał, krótki około dziewięciominutowy filmik z prezentacją możliwości tego narzędzia.

Werdykt

W komentarzach pod nagraniem umieściłem kilka moich przemyśleń. Moja radość nie miała końca, gdy okazało się, że to moje komentarze zasłużyły na wygraną w tym konkursie. Podziękowania za werdykt przesłałem drogą prywatnej korespondencji więc tutaj nie będę się więcej uzewnętrzniał.

Komentarze

Komentarze starłem się maksymalnie skracać, żeby nie odstraszać dużą ilością tekstu ale testowanie jednostkowe to temat bardzo rozległy. W skład tego tematu można wyróżnić takie obszary tematyczne jak: dobór narzędzi i bibliotek, techniki pisania testów, dobre i złe praktyki, zakres testowanego kodu, automatyczne uruchamianie testów, odseparowanie testów warstwą abstrakcji, koszt pisania testów, kto ponosi koszty pisania testów, czy testy spłacają się same, testy a inwestycją na przyszłość, niwelowanie długu technicznego, itp… Jak widać temat jest obszerny i moje komentarze mimo skracania również stały się nieco obszerne.

Poniżej zamieściłem zwycięskie komentarze wraz z odpowiedziami. Komentarzy umieściłem w taki sposób aby utworzyły zamkniętą rozmowę.

TEOVINCENT on 19/11/2014 22:54

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.

MACIEJ ANISEROWICZ on 21/11/2014 07:51