blog.testowka.pl

7 Grzechów Automatyzacji Testów

opublikowany przez 13, Lut, 2014, w kategoriach Inne

temptation

1. Wiara w cuda

Zbyt często automatyzacja jest postrzegana jako złote lekarstwo na problemy związane z niską jakością oprogramowania, która przejawia się poprzez dużą ilość defektów. Niektórym wydaje się, że jeśli przyspieszymy proces testowania poprzez jego zautomatyzowanie to od razu auto-magicznie będziemy popełniać mniej błędów. Warto jednak pamiętać o tym, że o ile automatyzacja szybciej pokaże nam widoczne objawy problemów z jakością naszego oprogramowania to tych problemów nie rozwiąże. Jak już pisałem wielokrotnie automatyzacja jedynie na poziomie testów end-to-end to za mało. Takie testy to jedynie początek, wstęp do refaktoryzacji mającej na celu poprawę jakości kodu.

2. Skróty nie zawsze są krótszą drogą

Nagrywanie i odtwarzanie testów automatycznych jest pokusą, której wielu początkującym praktykom automatyzacji ciężko jest się oprzeć. O ile samo wytworzenie takich skryptów może być faktycznie względnie szybkie i łatwe, o tyle ich późniejsze utrzymywanie bardzo szybko przeradza się w koszmar. Przeważnie po zmianie funkcjonalności okazuje się, że łatwiej było by nagrać wszystkie testy od nowa niż poprawić już istniejące. Chciwość nie jest najlepszym doradcą przy wyborze narzędzi do testów, co wcale nie znaczy, że trzeba wybierać te drogie i komercyjne – wręcz przeciwnie, darmowe rozwiązania open source, mocno wspierane przez community często okazują się być bardziej użyteczne od tych płatnych.

3. Kod testów nie jest przecież kodem produkcyjnym

Pisząc testy automatyczne musimy pamiętać o zasadach Clean Code tak samo jak powinniśmy o nich pamiętać pisząc kod funkcjonalności. Należy wziąć pod uwagę to, że kod testów będzie zmieniał się najprawdopodobniej tak często jak kod funkcjonalności o ile nie częściej, dlatego przestrzeganie zasad czystego kodu oraz stosowanie wzorców projektowych z pewnością zwróci się w postaci czasu zaoszczędzonego podczas późniejszych modyfikacji.

4. Testowanie End-To-End to za mało

Automatyzacja testów powinna odbywać się na każdym poziomie. Testowanie tylko na poziomie testów akceptacyjnych end-to-end czyli odwracanie klasycznej piramidy testów bardzo szybko prowadzi do jej destabilizacji i przewrócenia. Pomimo tego co zalecam zawsze podczas refaktoryzacji legacy code należy pamiętać o tym, że odwrócona piramida testów musi być sztucznie podpierana by się utrzymać. Dlatego by nasz wysiłek miał sens należy jak najszybciej wykorzystywać to co dają nam testy wysokiego poziomu i szybko budować podstawy piramidy.

5. Automatyzujmy wszystko

Jak często widzieliście projekty pod tytułem „Automatyzacja wszechświata”? Pamiętajmy, że im więcej testów napiszemy tym więcej będziemy ich musieli później utrzymywać. Co w takim razie testować? Z pewnością krytyczne funkcjonalności biznesowe wymagają pokrycia testami. Warto testować też to co się często zmienia. Oczywiście, że można przetestować wszystko – tylko po co? Im więcej testów tym więcej czasu będziemy czekać na informację zwrotną przy ich uruchomieniu. To co nie jest krytyczne powinno być oczywiście przetestowane na poziomie jednostkowym ale już niekoniecznie w testach end-to-end.

6. Automatyzacja to działka testerów

Klientami i głównymi użytkownikami testów automatycznych – nawet tych na poziomie testów akceptacyjnych są przede wszystkim programiści. Dlatego też powinni być oni zaangażowani w proces tworzenia tychże testów. Testy end-to-end nie mogą istnieć w zupełnym oderwaniu od tego co się aktualnie dzieje w kodzie funkcjonalności. Organizacje opierające swój development na konflikcie pomiędzy działem testów a działem programistów nie mają racji bytu we współczesnym środowisku wytwarzania oprogramowania. Coraz więcej organizacji (także tych dużych i wydawało by się skostniałych) rezygnuje w ogóle osobnych działów testowania i łączy testerów z programistami w zespoły wskroś-funkcjonalne.

7. Testy automatyczne nie wymagają ciągłej pracy

Automatyzacja testów to proces ciągły wymagający ciągłej uwagi i opieki. Podobnie jak wytwarzanie nowych funkcjonalności, automatyzacja testów również potrzebuje innowacji i ciągłych udoskonaleń. Czas poświęcony na dobrze zrobioną automatyzację zawsze się zwraca, ale nie zawsze od razu. Czasem trzeba trochę poczekać aż efekty będą widoczne. Albo właśnie nie będą widoczne efekty braku automatyzacji. Także decydując się na automatyzację testów zapomnij o pochwałach i spektakularnych sukcesach – możesz za to liczyć na minimalizacje ilości spektakularnych porażek.


1 Comment for this entry

  • Kazi

    Łatwo o błędy, jednak test solidnie napisany od początku może być wykorzystywany w rozwoju bez większych modyfikacji praktycznie.

Skomentuj