Unit Testing w praktyce… Czyli właściwie jak?

Piotr Raszkowski, 17.02.2015

Agenda

1. Moja historia stania się programistą - testerem.

2. Podstawy pisania testów jednostkowych.

3. Dobre praktyki pisania testów jednostkowych.

4. Rezultaty wykorzystania testów jednostkowych.

Dziwne...

Wczoraj to działało...

Jak to możliwe?

Coś jest nie tak w Twoich danych testowych...

Nie zmieniałem tego!

Czy na pewno testowałeś najnowszą wersję?

Nie mogę przetestować wszystkiego!

A już tego nie naprawiłem?

U mnie działa!

Moja historia...

1. Trudne po-studenckie początki...

Moja historia...

1. Trudne po-studenckie początki…2. Twarde lądowanie z powodu nie

testowania swojego kodu...

Moja historia...

1. Trudne po-studenckie początki…2. Twarde lądowanie z powodu nie

testowania swojego kodu…3. Nowa praca - nowe wyzwania.

Moja historia...

1. Trudne po-studenckie początki…2. Twarde lądowanie z powodu nie

testowania swojego kodu…3. Nowa praca - nowe wyzwania.4. Clean Code odmienił moje życie!

Moja historia...

1. Trudne po-studenckie początki…2. Twarde lądowanie z powodu nie

testowania swojego kodu…3. Nowa praca - nowe wyzwania.4. Clean Code odmienił moje życie!5. Testy na pierwszym miejscu!

Nie ma dobrego kodu bez dobrych testów!

Główne błędy

1. Brak świadomości programistów, że każdy popełnia błędy.

2. Brak ustandaryzowanego podejścia do testów.3. Brak jasnych zasad i standardów dbania o kod.4. Brak procesu review.5. Zbyt duża presja na wynik.6. Rozdzielenie testów od developmentu.

Podstawy pisania testów jednostkowych

Czy jest test jednostkowy?

Test jednostkowy (ang. unit test) – w programowaniu metoda testowania tworzonego oprogramowania poprzez wykonywanie testów weryfikujących poprawność działania pojedynczych elementów (jednostek) programu – np. metod lub obiektów w programowaniu obiektowym lub procedur w programowaniu proceduralnym. Testowany fragment programu poddawany jest testowi, który wykonuje go i porównuje wynik (np. zwrócone wartości, stan obiektu, zgłoszone wyjątki) z oczekiwanymi wynikami – tak pozytywnymi, jak i negatywnymi (niepowodzenie działania kodu w określonych sytuacjach również może podlegać testowaniu).

Źródło: Wikipedia

Test Driven Development

1. Nie można zacząć pisać kodu produkcyjnego do momentu napisania

niespełnianego testu jednostkowego.

2. Nie można napisać więcej testów jednostkowych, które są wystarczające

do niespełnienia testu, a brak kompilacji jest jednoczśnie nieudanym

testem.

3. Nie można pisać większej ilości kodu produkcyjnego, niż wystarczy do

spełnienia obecnie niespełnianego testu.

Źródło: Clean Code

TDD - dlaczego nie działa

● nastawienie na szybkie rezultaty

● bardzo trudne

● wymaga “przemyślenia” wszystkiego na początku

Czystość testów

● Testy powinny być czytelne (klarowne, proste, spójne)!● Brak czytelności prowadzi do niechęci zmian kodu

produkcyjnego.● Brak czytelności prowadzi do braku nowych testów.● Brak czytelności prowadzi do wzrostu kosztu

utwrzymania.

● Czytelność zwiększa możliwości!

Jedna asercja VS jedna koncepcja

Zasada F.I.R.S.T.

1. fast (szybkie)2. independent (niezależne)3. repeatable (powtarzalne)4. self - validating (samokontrolujące się)5. timely (o czasie)

Dobre praktyki pisania testów jednostkowych

Testy prawdziwie jednostkowe

● testujemy tylko i wyłącznie jedną klasę - inaczej to testy integracyjne

Testy prawdziwie jednostkowe

● testujemy tylko i wyłącznie jedną klasę - inaczej to testy integracyjne

● testujemy tylko jedną koncepcję na metodę testową

Testy prawdziwie jednostkowe

● testujemy tylko i wyłącznie jedną klasę - inaczej to testy integracyjne

● testujemy tylko jedną koncepcję na metodę testową

● nie testujemy zależności - mock’ujemy

Testy prawdziwie jednostkowe

● testujemy tylko i wyłącznie jedną klasę - inaczej to testy integracyjne

● testujemy tylko jedną koncepcję na metodę testową

● nie testujemy zależności - mock’ujemy● testujemy warunki brzegowe

Używamy dodatkowych bibliotek i narzędzi

● Mockito● PowerMock● EasyMock● Cobertura● EclEmma

Tworzymy testy “integracyjne”

Pokrycie kodu...

… powinno wynosić 100%!

Nie piszemy komentarzy, piszemy testy!

Opisujemy zachowania

● Metody testowe opisują zachowania● Metody testowe opisują warunki wejścia

oraz zakładany rezultat● Gdy za dużo warunków wejściowych →

rozbijamy klasy na mniejsze (SRP)

Jak pracować z testami?

1. Piszemy testy na początku (zbyt idealne).2. Piszemy kod programu (zgrubny szkic).3. Pokrywamy kod testami.4. Prowadzimy refactoring przy ciągłym uruchamianiu

testów.

Zasada Scout’a w testach

1. Po każdej zmianie w kodzie badamy pokrycie.2. Wyszukujemy klasę o niskim pokryciu.3. Ulepszamy!

Tworzymy testowalny kod

● czasami warto zmienić poziom dostępu● unikamy ciężkiej logiki w konstruktorach● unikamy statycznych funkcji● unikamy

anty-wzorca Singleton

Zasada Given-When-Then

● jedna koncepcja na test● każda metoda testowa rozdzielona na bloki:

o given → wejście do naszej metodyo when → zachowanieo then → zakładany rezultat

● Given-When-Then w nazwach metod testowych

Rezultaty stosowania testów

Aplikacja do ekstrakcji danych

● Ilośc linii kodu: 4 138 (4 053 / 85 - 97,9 %)● Ilość klas: 250 (246 / 4 - 98,4 %)● Ilość metod: 1 342 (1296 / 46 - 96,6 %) ● Ilość napisanych testów: 1 077

● Pokrycie kodu (instrukcje): 97,2 %

Rezultaty

● Ilość poważnych błędów: 1● Ilość mniejszych błędów: ~10● Ilość sytuacji w których aplikacja w ogóle

nie zadziałała: 0

● Niezliczona ilość operacji refactoringu i zmian w kodzie.