Wprowadzenie do testów jednostkowych

Marcin Samsonowski@msamson37

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ć?

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ć?

Testowanie – ale o co chodzi?

Testowanie – ale o co chodzi?

Czym jest testowanie?

Testowanie – ale o co chodzi?

Zarządzanie jakością - proces mający na celu zapewnienie wysokiej jakości dostarczanego produktu.

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).

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 problemomQC – znajdywanie problemów

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.

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ć?

Dlaczego automatyzować testy?

Dlaczego automatyzować testy?

- Automatyzacja powtarzalnych czynności to oszczędność czasu

Dlaczego automatyzować testy?

- Automatyzacja powtarzalnych czynności to oszczędność czasu- Brak automatyzacji jest groźny!

Dlaczego automatyzować testy?

- Automatyzacja powtarzalnych czynności to oszczędność czasu- Brak automatyzacji jest groźny!- Wymusza lepsze projektowanie oprogramowania

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

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ą

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

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

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ę

Pogromcy mitów: dlaczego nie automatyzować?

“Przecież mamy najlepszych testerów – użytkowników”

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• …

Pogromcy mitów: dlaczego nie automatyzować?

“Nie mamy czasu na testowanie”

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

Pogromcy mitów: dlaczego nie automatyzować?

"Uruchamianie testów to dodatkowy narzut pracy i czasu"

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

Pogromcy mitów: dlaczego nie automatyzować?

"Kod jest trudny / niemożliwy do przetestowania"

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

Pogromcy mitów: dlaczego nie automatyzować?

"Nie płacą mi za pisanie testów“

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?

Pogromcy mitów: dlaczego nie automatyzować?

"Póki co się kompiluje, a jak trzeba będzie to zdebuguję"

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

Pogromcy mitów: dlaczego nie automatyzować?

“Legacy code, nie ma sensu pokrywać testami tylko małej części”

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

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ć?

Klasyfikacja testów

Różne kryteria:• Poziom granularności• Przezroczystość• Typ• Warstwa testowana

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

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…

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

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!

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?

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.

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?

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)

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 )

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.• …

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

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ć?

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?

Testy jednostkowe - DEMO

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ć?

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.

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/

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

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

Double

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

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

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

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

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

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)

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ć?

Co i jak testować?

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

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

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?

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?

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ć?• …

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• …

Ź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

Dziękuję!

I proszę o feedback!

Marcin Samsonowski@msamson37