Unit testing w praktyce... czyli właściwie jak?
-
Upload
bartlomiej-cymanowski -
Category
Technology
-
view
3.294 -
download
1
Transcript of Unit testing w praktyce... czyli właściwie jak?
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.