poniedziałek, 6 stycznia 2014

wstęp do testowania



Testy - temat rzeka.
Na sam początek naszej przygody z testami podam przykład z życia, bo uważam że takie są najlepsze.
Kiedyś jakiś programista powiedział mi, że zna Spring Security.

Odpowiedziałem mu, że fajnie.
Ale Spring Security to duży temat.




Uważam to, że to jeden z najbardziej przydających się zrębów oprogramowania dla większości programistów.
A dla tych którzy implementują rozwiązania webowe to podstawa.

Co prawda możemy go zastąpić Apache Shiro w większym lub mniejszym stopniu zależnym od projektu ale i tak Spring Security stanowi od dla mnie bazowy framework do rozwiązań security w moich aplikacjach.

Wracając do tematu. Skoro znasz to pewnie potrafisz przetestować swoją funkcjonalność bez odpalania kontenera webowego ?:) - odpowiedziałem.
A on : no jak to ...i czy tak w ogóle można?

Pomyślałem sobie jak nie umiesz przetestować tego co zrobiłeś to gówno znasz Spring Security. Albo, że jego wiedza jest lakoniczna.
Czasem jest też tak, że ktoś przeczyta byle jaki tutorial i uważa się za znawcę tematu. Ja z kolei raczej nie staram się wyprowadzić go z błędu no chyba, że nieźle mnie wkur.....

Przykład Spring Security mogę zastąpić tematem: REST, MVC, WS, etc.
To wszystko da się przetestować:)

Teraz Ty sam musisz zadać sobie takie pytanie : czy potrafię przetestować każdy kawałek swojego softu ?  

Pisząc odpowiedni test dam Ci wiarę, że jesteś wysokich lotów fachowcem.
Po pierwsze przetestowałeś swój kod. Teraz masz pewność, że działa.
Po drugie otworzyłeś drogę do przyszłej refaktoryzacji systemu.
Po trzecie zrobiłeś dokumentację. Lepszej już nie da się wykonać.
Opisałeś funkcjonalność klasy czy danego modułu (BDD).
Po czwarte sprawdziłeś czy zaimplementowałeś wszystkie wymagania biznesowe danego obszaru.
Po piąte dowiodłeś, że Twoje rozwiązanie jest wydajne i działa stabilnie współpracując z innymi komponentami w systemie.

Mogę wliczać tak dalej ale o tym opowiem już potem w następnych postach z serii testowalność (testability).

W każdym unit test musi mieć cechy takie jak:
 - niezależność
 - powtarzalność
 - jednoznaczność
 - jednostkowość
 - szybkość wykonania
 - wysokie prawdopodobieństwo wykrycia błędu

W zamian otrzymamy oprogramowanie charakteryzujące się :
 - operatywnością
 - obserwowalnością
 - sterowalnością
 - dekompozycją
 - prostotą
 - stabilnością
 - zrozumiałością

 Poniżej przedstawie diagram znanych mi rodzajów testów.

Tworząc testy możemy wpierać się piramidą testów, jak na rysunku poniżej.
TIP : Proporcje rodzajów testów w Twoim projekcie też są ważne.



















W późniejszych blogach rozwiniemy każdy rodzaj testów. I na żywym organizmie czyli realnym kodzie docenimy ich wartość.

cdn.





Brak komentarzy:

Prześlij komentarz