Ola Kunysz
Jedna liczba
W wielu projektach ustalany jest wymagany procent pokrycia kodu testami. Wynika to najczęściej z tego, że chcemy kogoś „zmusić” do pisania testów, więc tworzymy jakiś KPI (Key Performance Indicator). Ta liczba pojawia się w definition of done i teoretycznie możemy spać spokojnie. Jest tylko jeden problem. Nie określamy jakości tych testów. Kiepskie testy nie dają nam żadnej pewności przy pisaniu implementacji, czy refaktoryzowaniu kodu.
Żeby z ciekawości sprawdzić, jaki jest code coverage Twojego projektu, nie potrzebujesz żadnych skomplikowanych narzędzi. Nie musisz też czekać na informację zwrotną z CI. Wystarczy użyć wtyczki do Twojego IDE albo użyć wbudowanej funkcjonalności, np. w IntelliJ (Run > Show Code Coverage Data). Poznasz tę jedną magiczną liczbę, ale też zobaczysz, które linijki w kodzie są pokryte. Na przykład, ta metoda teoretycznie jest pokryta w 100%:
Chociaż zakomentowałam asercję i metoda jest tylko wywoływana w teście:
Może zastanawiasz się kto miałby pisać takie testy? Widziałam je wiele razy w różnych projektach. Powody były różne. Ktoś nie wiedział, co chce przetestować, więc tak zostawił. Ktoś inny odszedł od klawiatury i zapomniał. Jeszcze ktoś inny chciał dążyć do 100% pokrycia kodu testami... No właśnie, rośnie to, co mierzymy. Jeśli mierzymy ilość testów, to w górę będzie szła jedna magiczna liczba, a nie jakość projektu. Kiedyś Sebastian Malaca pisał w magazynie Programista o tym, jak code coverage jako miara może nam zaszkodzić...
Ile testów pisać?
Nie jestem fanką ustalania sztywnych granic pokrycia kodu testami, ponieważ powstają wtedy bardzo dziwne i niepotrzebne testy, żeby tylko spełnić kryteria. Natomiast bardzo lubię pisać testy, zwłaszcza tam, gdzie ich brakuje. Na przykład, kiedy naprawiam błąd, zaczynam od napisania nieprzechodzącego testu. Kiedy test się zazieleni, wiem, że napisałam dobrą implementację i że zapobiegnę w ten sposób regresji w przyszłości. Kiedy napiszę test i jest od razu zielony, to znaczy, że jeszcze nie rozumiem problemu, który wystąpił. Wtedy muszę dopisać kolejny test.
Kiedy piszę nowe funkcjonalności, nie zawsze wiem, co dokładnie może pójść nie tak. Pokrywam więc testami tylko postawowe scenariusze. Zazwyczaj przed wejściem na produkcję funkcjonalność jest dyskutowana z zespołem. Pojawiają się wtedy nowe scenariusze i pomysły na testy. Nie trzymam się jednak sztywnych granic procentowych, tylko staram się zapewnić sobie spokój ducha, że mój kod działa jak należy.
A jakie Ty masz podejście do pisania testów? Zakładasz sobie jakiś minimalny pułap i utrzymujesz go? Czy to raczej zależy od części projektu?
