Dzisiaj Janek zadał mi pytanie:

Jak zdefiniować stabilność w sensie CI?

Problem związany jest z kilkoma narzędziami, które chciałbym zaprezentować w ramach tego cyklu.

Dżentelmeńska umowa

Inaczej nie można nazwać tego jak działają zasady, którymi kierujemy się przy określaniu standardów kodu. Każdy zespół powinien sam wypracować sobie taki standard i przyjąć go jako jedyny słuszny. Pytanie jak to jest związane z moim warsztatem. Otóż dzięki standaryzacji można w łatwy sposób utrzymywać kod. Jeżeli wiemy, że klasy są generowane według jakiegoś szablonu to zapuszczenie awk czy sed na kodzie nie sprawia problemu. Dodatkowo wszyscy wiedzą gdzie szukać jakiś elementów.
Można zatem powiedzieć, że odpowiedni cyrograf ułatwia życie i pracę całego zespołu.

Ustalenie zasad

Zasady o których tu będzie mowa nie są formalne. Zresztą ciężko mówić o formalizmie w odniesieniu do wspomnianej wcześniej dżentelmeńskiej umowy. Zasady te dotyczą kilku aspektów. Część z nich można kontrolować automatycznie przy pomocy różnych narzędzi. Części nie da się kontrolować w prosty sposób, ale można odpowiednio karać za nieprzestrzeganie.

Testy – nazewnictwo

Pierwszą grupę zasad stanowią te dotyczące testów. Opisują one zasady nazywania klas i metod testowych, grupowania ich w pakiety oraz sposobu dokumentacji. Ważne jest tu przyjęcie jednolitych zasad ponieważ można wtedy łatwo odszukać potrzebny kawałek.
Przykładowo jeżeli testujemy metodę doSth(Boolean) należąca do klasy SthClass to nazwy testów mogą wyglądać w następujący sposób doSthTrueTest() i doSthFalseTest() oraz doSthNullTest() całość w klasie SthClassTest. Patrząc na tak nazwany kod od razu wiadomo co i jak.
Oczywiście nie zwalnia to nikogo od napisania javadoców, które będą tłumaczyły co oznacza dany test w sensie biznesowym. Jakiemu elementowi procesu odpowiada. Niestety tu jak zawsze na drodze staje brak czasu…

Testy – pokrycie

Tu kolejna ważna rzecz, która łączy się z następnym punktem tego wpisu. Należy przyjąć jakieś rozsądne zasady dotyczące określenia co znaczy „kod przetestowany”. Zazwyczaj można określić dwie standardowe metryki (lol! mądre słowo na blogu). Pierwsza z nich to procent linii kodu, które zostały przetestowane. Druga to procent rozgałęzień (warunków if/else) w kodzie, które zostały przetestowane. Warto też wybrać część kodu, która nie będzie testowana. Zazwyczaj jest to kod generowany automatycznie np. klienci WebServices lub obiekty JPA. Taki kod co do zasady nie powinien być testowany. Traktujemy go jako „czarną skrzynkę” dostarczoną z zewnątrz. Szkoda po prostu na to czasu.

Dokumentacja

Kolejny ważny element. Pytanie brzmi czy piszemy dokumentację czy też nie. Jestem zwolennikiem pisania dużej dokładnej dokumentacji. Z własnego doświadczenia wiem, że brak dokumentacji jest bardzo bolesny. Zazwyczaj nie chce się mi jej pisać, ale zmuszam się.

Spis narzędzi

Przed kolejnym odcinkiem krótki spis narzędzi, które będę omawiał w kolejnej części.

  • Cobertura jest narzędziem, które pozwala na sprawdzenie jaka część kodu została przetestowana
  • Checkstyle sprawdza czy kod jest prawidłowo sformatowany, skomentowany i generalnie ładny. Bardzo elastyczne narzędzie.
  • PMD, służy do wyszukiwania duplikującego się kodu
  • JDepend, wylicza metryki obiektowe. Czasami się przydaje by sprawdzić jak elastyczny jest nasz kod.
  • Findbugs na podstawie analizy kodu źródłowego wyszukuje miejsca potencjalnie niebezpieczne.

Całość zapięta mavenem…