An introduction to unit testing

1. Wprowadzenie do
testów jednostkowych
Marcin Samsonowski
@msamson37

2. Agenda
• Testowanie – ale o co chodzi?
• Czy i dlaczego warto automatyzować testy?
• Klasyfikacja testów
• Testy jednostkowe w teorii i praktyce
• Mock, stub, fake… czyli szkoła udawania 
• Co i jak testować?

3. Agenda
• Testowanie – ale o co chodzi?
• Czy i dlaczego warto automatyzować testy?
• Klasyfikacja testów
• Testy jednostkowe w teorii i praktyce
• Mock, stub, fake… czyli szkoła udawania 
• Co i jak testować?

4. Testowanie – ale o co chodzi?

5. Testowanie – ale o co chodzi?
Czym jest testowanie?

6. Testowanie – ale o co chodzi?
Zarządzanie jakością - proces mający na celu zapewnienie wysokiej
jakości dostarczanego produktu.

7. Testowanie – ale o co chodzi?
Zarządzanie jakością - proces mający na celu zapewnienie wysokiej
jakości dostarczanego produktu.
Testowanie (quality control, QC), podobnie jak
zapewnianie jakości (quality assurance, QA)
to jeden z elementów zarządzania jakością (quality management).

8. Testowanie – ale o co chodzi?
Zarządzanie jakością - proces mający na celu zapewnienie wysokiej
jakości dostarczanego produktu.
Testowanie (quality control, QC), podobnie jak
zapewnianie jakości (quality assurance, QA)
to jeden z elementów zarządzania jakością (quality management).
QA – zapobieganie problemom
QC – znajdywanie problemów

9. Testowanie – ale o co chodzi?
Testowanie – poddawanie produktu próbie, tak aby sprawdzić, czy w
zadanych warunkach produkt zachowuje się tak jak tego oczekujemy.
Po to, aby znaleźć ewentualne problemy przed użytkownikiem.

10. Agenda
• Testowanie – ale o co chodzi?
• Czy i dlaczego warto automatyzować testy?
• Klasyfikacja testów
• Testy jednostkowe w teorii i praktyce
• Mock, stub, fake… czyli szkoła udawania 
• Co i jak testować?

11. Dlaczego automatyzować testy?

12. Dlaczego automatyzować testy?
- Automatyzacja powtarzalnych czynności to oszczędność czasu

13. Dlaczego automatyzować testy?
- Automatyzacja powtarzalnych czynności to oszczędność czasu
- Brak automatyzacji jest groźny!

14. Dlaczego automatyzować testy?
- Automatyzacja powtarzalnych czynności to oszczędność czasu
- Brak automatyzacji jest groźny!
- Wymusza lepsze projektowanie oprogramowania

15. Dlaczego automatyzować testy?
- Automatyzacja powtarzalnych czynności to oszczędność czasu
- Brak automatyzacji jest groźny!
- Wymusza lepsze projektowanie oprogramowania
- Drastyczna redukcja czasu spędzonego na debuggowaniu

16. Dlaczego automatyzować testy?
- Automatyzacja powtarzalnych czynności to oszczędność czasu
- Brak automatyzacji jest groźny!
- Wymusza lepsze projektowanie oprogramowania
- Drastyczna redukcja czasu spędzonego na debuggowaniu
- Jedynie testy na aktualnym kodzie coś znaczą

17. Dlaczego automatyzować testy?
- Automatyzacja powtarzalnych czynności to oszczędność czasu
- Brak automatyzacji jest groźny!
- Wymusza lepsze projektowanie oprogramowania
- Drastyczna redukcja czasu spędzonego na debuggowaniu
- Jedynie testy na aktualnym kodzie coś znaczą
- Testy mogą być świetną (i aktualną) dokumentacją kodu

18. Dlaczego automatyzować testy?
- Automatyzacja powtarzalnych czynności to oszczędność czasu
- Brak automatyzacji jest groźny!
- Wymusza lepsze projektowanie oprogramowania
- Drastyczna redukcja czasu spędzonego na debuggowaniu
- Jedynie testy na aktualnym kodzie coś znaczą
- Testy mogą być świetną (i aktualną) dokumentacją kodu
- Testy dają dowód, że coś działa

19. Dlaczego automatyzować testy?
- Automatyzacja powtarzalnych czynności to oszczędność czasu
- Brak automatyzacji jest groźny!
- Wymusza lepsze projektowanie oprogramowania
- Drastyczna redukcja czasu spędzonego na debuggowaniu
- Jedynie testy na aktualnym kodzie coś znaczą
- Testy mogą być świetną (i aktualną) dokumentacją kodu
- Testy dają dowód, że coś działa
- Testy ułatwiają pracę

20. Pogromcy mitów: dlaczego nie automatyzować?
“Przecież mamy najlepszych testerów – użytkowników”

21. Pogromcy mitów: dlaczego nie automatyzować?
“Przecież mamy najlepszych testerów – użytkowników”
• Nie zawsze możemy sobie na to pozwolić
• Zbyt wysoki koszt błędu w wielu zastosowaniach
• Medycyna
• Loty kosmiczne
• Mechanika
• …

22. Pogromcy mitów: dlaczego nie automatyzować?
“Nie mamy czasu na testowanie”

23. Pogromcy mitów: dlaczego nie automatyzować?
“Nie mamy czasu na testowanie”
• Głównie amatorzy, którzy nie rozumieją testowania
• Testujemy (a przynajmniej powinniśmy) zawsze. Ręcznie lub
automatycznie
• Kluczowe określenie użyteczności automatyzacji
• Timing - kod produkcyjny tworzony jednocześnie z testowym
• Przełączanie kontekstu I praca wejścia
• Zapobieganie efektom motyla

24. Pogromcy mitów: dlaczego nie automatyzować?
"Uruchamianie testów to dodatkowy narzut pracy i czasu"

25. Pogromcy mitów: dlaczego nie automatyzować?
"Uruchamianie testów to dodatkowy narzut pracy i czasu“
• Serio? Nawet testy trwające bardzo długo można:
• Odpalić I zająć się swoją robotą
• Zintegrować np z build serverem
• Zautomatyzować ich uruchamianie

26. Pogromcy mitów: dlaczego nie automatyzować?
"Kod jest trudny / niemożliwy do przetestowania"

27. Pogromcy mitów: dlaczego nie automatyzować?
"Kod jest trudny / niemożliwy do przetestowania“
• Czasami faktycznie tak jest
• Złoty środek – automatyzować gdy się to opłaca

28. Pogromcy mitów: dlaczego nie automatyzować?
"Nie płacą mi za pisanie testów“

29. Pogromcy mitów: dlaczego nie automatyzować?
"Nie płacą mi za pisanie testów“
• To prawda. Za pisanie kodu też nie. Płacą za dostarczanie produktu
• Pomagasz przede wszystkim sobie dbając za wczasu o jakość
• Testerzy w zespole
• Nie wyślesz ich na bezrobocie 
• Im mniej Twoich baboli ujrzy światło dzienne, tym lepiej
• Mogą się zająć szukaniem innych / bardziej zaawansowanych błędów
• Lepiej, żebym bugi znalazł ja sam czy tester?

30. Pogromcy mitów: dlaczego nie automatyzować?
"Póki co się kompiluje, a jak trzeba będzie to zdebuguję"

31. Pogromcy mitów: dlaczego nie automatyzować?
"Póki co się kompiluje, a jak trzeba będzie to zdebuguję“
[tricky] Znajdź subtelną różnicę:
• “Kompiluje się” vs “dzieje się dokładnie to co powinno”
• Debuggowanie vs przeglądanie raportu samo opisujących się testów
wraz z ich wynikami wykonania

32. Pogromcy mitów: dlaczego nie automatyzować?
“Legacy code, nie ma sensu pokrywać testami tylko małej części”

33. Pogromcy mitów: dlaczego nie automatyzować?
“Legacy code, nie ma sensu pokrywać testami tylko małej części”
Czy testy mają sens bez 100% pokrycia? Zależy.
• Utrzymywanym projektom należy się czasem refactoring
• Refactoring => lepszy design
• Dobry design => dopisanie testów nie powinno stanowić problemu
• Niewiele testów > brak testów
• Większe przeróbki => testy pomagają!
• Lepsze czasy => więcej testów 

34. Agenda
• Testowanie – ale o co chodzi?
• Czy i dlaczego warto automatyzować testy?
• Klasyfikacja testów
• Testy jednostkowe w teorii i praktyce
• Mock, stub, fake… czyli szkoła udawania 
• Co i jak testować?

35. Klasyfikacja testów
Różne kryteria:
• Poziom granularności
• Przezroczystość
• Typ
• Warstwa testowana

36. Klasyfikacja testów - poziom granularności
• Testy jednostkowe (modułowe) - komponenty, które można odizolować

37. Klasyfikacja testów - poziom granularności
• Testy jednostkowe (modułowe) - komponenty, które można odizolować
• Testy integracyjne
• wewnętrzne (międzymodułowe) – interfejsy między modułami
• zewnętrzne (międzysystemowe) – oddziaływania między częściami systemu -
systemem operacyjnym, systemem plików, podłączonymi urządzeniami…

38. Klasyfikacja testów - poziom granularności
• Testy jednostkowe (modułowe) - komponenty, które można odizolować
• Testy integracyjne
• wewnętrzne (międzymodułowe) – interfejsy między modułami
• zewnętrzne (międzysystemowe) – oddziaływania między częściami systemu
takimi jak system operacyjny, system plików, podłączone urządzenia itp
• Testy systemowe – system / produkt

39. Klasyfikacja testów - poziom granularności
• Testy jednostkowe (modułowe) - komponenty, które można odizolować
• Testy integracyjne
• wewnętrzne (międzymodułowe) – interfejsy między modułami
• zewnętrzne (międzysystemowe) – oddziaływania między częściami systemu
takimi jak system operacyjny, system plików, podłączone urządzenia itp
• Testy systemowe – system / produkt
• Testy akceptacyjne
• Zwykle użytkownik systemu sprawdza niezawodność systemu i zgodność z
wymaganiami niefunkcjonalnymi (np. performance). Nie mylić z odbiorem!

40. Klasyfikacja testów - przezroczystość
Testy czarnej skrzynki (black box)
• Brak wglądu w kod, jedynie działający produkt.
• Przypadki testowe układane na podstawie specyfikacji I wymagań.
• Szukanie różnic między wymaganiami a stanem rzeczywistym.
• Wady i zalety?

41. Klasyfikacja testów - przezroczystość
Testy czarnej skrzynki (black box)
+ Tester może być nietechniczny I nie znać wykorzystywanych technologii
Wystarczy, że dostanie specyfikację, nie musi nawet pracować przy projekcie.
+ Projektowanie testów możliwe jak tylko dostaniemy specyfikację
projektu
- Trudność I czasochłonność rozpoznania większości (w tym
specyficznych) możliwych scenariuszy.

42. Klasyfikacja testów - przezroczystość
Testy białej skrzynki (white box, glass box)
• Jest wgląd w kod. Testujemy wewnętrzną strukturę produktu.
• Możliwość skoncentrowania na tych częściach kodu, gdzie istnieje
zwiększone ryzyko występowania błędów.
• Wady I zalety?

43. Klasyfikacja testów - przezroczystość
Testy białej skrzynki (white box, blass box)
+ Znając strukturę kodu, dużo łatwiej rozpoznać co może się w nim
“zepsuć” i jak go efektywnie testować
+ Łatwiej odseparować małe części systemu I testować je niezależnie
- Wymagana znajomość struktury kodu
- Wymagane umiejętności programistyczne (wyższy koszt)

44. Klasyfikacja testów - typy
• Functional testing - testowanie zgodności z wymaganiami funkcjonalnymi
• Smoke testing - testowanie działania pod niewielkim obciążeniem
• Stress testing - testowanie działania pod dużym obciążeniem przez dłuższe
okresy czasu
• Performance testing - testowanie responsiveness systemu
• Load testing - testowanie responsiveness z podłączonymi wieloma klientami
• Incremental integration testing - testowanie nowo dodanego kodu
• Mutation testing - jak incremental integration, ale testowanie jedynie kodu
naprawiającego jakiegoś buga
• Regression testing - testy regresyjne (tego co już działało )

45. Klasyfikacja testów - typy
• Security testing - testowanie stopnia w jakim system jest w stanie się obronić
przed nieautoryzowanym dostępem itp
• Ad-hoc testing - bez przygotowanych przypadków testowych
• Exploratory testing - jak ad-hoc, ale ma na celu zapoznanie się z produktem
• Usability testing - testowanie user-friendliness
• Alfa & beta testing - przeprowadzane przez potencjalnych odbiorców
produktu mają na celu uzyskanie feedbacku. Alfa odbywają się najczęściej w
siedzibie wytwórcy oprogramowania a beta po stronie odbiorcy.
• …

46. Klasyfikacja testów – warstwa systemu
• Warstwa danych
• Warstwa logiki biznesowej (testy funkcjonalne)
• API
• UI

47. Agenda
• Testowanie – ale o co chodzi?
• Czy i dlaczego warto automatyzować testy?
• Klasyfikacja testów
• Testy jednostkowe w teorii i praktyce
• Mock, stub, fake… czyli szkoła udawania 
• Co i jak testować?

48. Testy jednostkowe
• Test jednostkowy (unit test) – sprawdza, czy pewien mały i specyficzny
kod odpowiadający za pewną funkcjonalność robi to, czego od niego
oczekujemy.
• Czego trzeba, abyś i Ty mógł pisać UT?

49. Testy jednostkowe - DEMO

50. Agenda
• Testowanie – ale o co chodzi?
• Czy i dlaczego warto automatyzować testy?
• Klasyfikacja testów
• Testy jednostkowe w teorii i praktyce
• Mock, stub, fake… czyli szkoła udawania 
• Co i jak testować?

51. Mock, stub, fake…
Częsty problemem w “testach jednostkowych”: rozrastanie się one z
uwagi na zależności między "jednostkami".
Skomplikowane inicjalizacje obiektów, odwołania do baz danych,
serwisów czy urządzeń zewnętrznych. To wszystko przekształca test
jednostkowy w integracyjny, i nie pozwala na izolację.
Kiedy nie sposób naturalnie oddzielić “jednostki” na potrzeby
testowania, z pomoca przychodzą dublerzy.

52. Mock, stub, fake…
Na początek słów kilka o różnicach:
"All fake objects are just that – fakes – the use of the fakes
determines whether they’re mocks or stubs“
(FakeItEasy – mocking tool) https:// github.com/FakeItEasy/FakeItEasy
https://code.google.com/p/fakeiteasy/

53. Mock, stub, fake…
Na początek słów kilka o różnicach:
“No need to learn what’s the theoretical difference between a
mock, a stub, a fake, a dynamic mock, etc.“
(Strona projektu Moq - mocking tool) https ://github.com/Moq/moq4
“Mock, stub, fake, spy, test double? Strict or loose? Nah, just
substitute for the type you need!”
(Strona projektu NSubstitute) http ://nsubstitute.github.io

54. Mock, stub, fake…
Mock, stub, fake, dummy, double…
Czym są? Czym się różnią? Po mału.
Używamy ich w następujący sposób:
• Opisz interfejsem metody dla obiektu
• Zaimplementuj interfejs dla kodu produkcyjnego
• Zaimplementuj interfejs dla kodu testowego

55. Double
• Dubler
• Reprezentuje każdy obiekt “udający”: mock, stub, fake, dummy, …
• Naśladuje rzeczywistą klasę na potrzeby odizolowania od niej

56. Dummy
• Największy prymityw. Jak nazwa wskazuje 
• Używany, gdy zupełnie nie interesuje nas co dana klasa robi, ale
musimy go “mieć” aby wykonać test (np. wymagany argument
metody)
• Nic nie robi (cały dzień)
• Pożytek z niego taki, że samemu nic nie robiąc gwarantuje, że
testujemy to co chcemy – czyli nie jego.
• Demo

57. Stub
• Zwraca zdefiniowaną przez nas i przewidywalną wartość.
• Używany w testach weryfikujących stan obiektów.
• Sprawdzanie którejś właściwości obiektu albo zwracanej wartości
• Demo

58. Mock
• Często mylony w nazewnictiwie ze stubem (i nie tylko).
• Paradoksalnie najbardziej się różni od pozostałych.
• Używany w testach sprawdzających zachowania obiektów.
• Chodzi o sprawdzenie, czy obiekt jest używany tak jak byśmy tego chcieli.
• Prawie zawsze testowanie odbywa się przy pomocy mocking framework.
• Zamiast zwracanej wartości definiujemy np jaka metoda powinna zostać
wykonana.
• Możliwe także definiowanie jakie parametry powinny zostać przekazane,
jakie metody oraz operacje na właściwościach są dozwolone itp.
• Demo

59. Fake
• Zawiera pewną logikę.
• Uproszczoną w stosunku do obiektu, który naśladuje.
http://www.yummymummyclub.ca/blogs/
anne-radcliffe-dinner-its-not-rocket-science/
20141210/epic-eggnog-just-for-you

60. Doubles - podsumowanie
• Dummy – nie robi nic
• Stub – zwraca zdefiniowaną przez nas wartość, służy do sprawdzania
stanu
• Mock – pozwala na sprawdzenie, czy testowany obiekt jest używany
tak, jak byśmy tego chcieli
• Fake – posiada uproszczoną logikę
W rzeczywistości framework nie bawią się w nazewnictwo, tylko
skupiają się na tym o co w tym wszystkim chodzi – udawaniu (izolacji).
Przykłady: FakeItEasy (fakes), Moq (mocki)

61. Agenda
• Testowanie – ale o co chodzi?
• Czy i dlaczego warto automatyzować testy?
• Klasyfikacja testów
• Testy jednostkowe w teorii i praktyce
• Mock, stub, fake… czyli szkoła udawania 
• Co i jak testować?

62. Co i jak testować?

63. Co i jak testować?
General principles:
• Test anything that might break
• Test everything that does break
• New code is guilty until proven innocent
• Write at least as much test code as production code
• Run local tests with each compile
• Run all tests before check-in to repository

64. Co i jak testować?
A-TRIP, czyli właściwości dobrze napisanych testów:
• Automatic - wykonywanie testów nie powinno wymagać >1 kliknięcia
• Thorough – szczegółowość – należy sprawdzać wszystko, co jest
istotne i może zawieść
• Repeatable – test zawsze powinien zwracać ten sam rezultat
• Independent – każdy test jest niezależny od każdego innego, od
kolejności wykonania I wszystkiego co go otacza (zmienne itp)
• Professional – kod testowy powinien spełniać te same, wysokie
wymagania co kod produkcyjny

65. Co i jak testować?
Right-BICEP, czyli co testować
• Are the results right?
• Are all the boundary conditions CORRECT?
• Can you check inverse relationships?
• Can you cross-check results using other means?
• Can you force error conditions to happen?
• Are performance characteristics within bounds?

66. Co i jak testować?
CORRECT, czyli co testować cd
• Conformance – does the value conform to an expected format?
• Ordering – is the set of values ordered or unordered as appropriate?
• Range – is the value within reasonable minimum and maximum values?
• Reference – d0es the code reference anything external that isn’t under direct
control of the code itself?
• Existence – does the value exist? (e.g. is non-null, non-zero, present in set, etc.)
• Cardinality – are there exactly enough values?
• Time (absolute and relative) – is everything happening in order? At the right
time? In time?

67. Agenda
• Testowanie – ale o co chodzi?
• Czy i dlaczego warto automatyzować testy?
• Klasyfikacja testów
• Testy jednostkowe w teorii i praktyce
• Mock, stub, fake… czyli szkoła udawania 
• Co i jak testować?
• … 

68. Podsumowanie
• Wszyscy jesteśmy testerami 
• Automatyzacja ułatwia nam pracę i życie
• Testy jednostkowe poddają próbie elementarne komponenty
odizolowane od zależności, sprawdzając ich wąską funkcjonalność
• Czasem udawanie się przydaje
• …

69. Źródła
• … “tego kwiatu jest pół światu”
• Pragmatic Unit Testing in Csharp with Nunit;
Andy Hunt, Dave Thomas, Matt Hargett
• The Art of Unit Testing with Examples in .NET; Roy Osherove
• http://hanselminutes.com/169/the-art-of-unit-testing-with-roy-
osherove
• Software System Testing and Quality Assurance; Boris Beizer

70. Dziękuję!
I proszę o feedback!
Marcin Samsonowski
@msamson37