Strategie automatyzacji testow
- 1. Strategie Automatyzacji Testów Wiktor Żołnowski www.agileszkolenia.pl facebook.com/CodeSprinters
- 3. Automatyzacja Testów w projektach typu “green field” ● Piramida Testów ● Continuous Integration ● Test-Driven Development ● Behavior-Driven Development ● Continuous Delivery
- 4. Testy End-to-end - ~10% •Testy funkcjonalne - ~20% •Testy Jednostkowe - ~70% Piramida Testów
- 6. Continuous Integration - Praktyki ● Repozytorium Kodu ● Automatyczny Build ● Każda zmiana jest testowana w środowisku testowym ● Build powinien być samo-testujący się ● Build powinien być szybki ● Środowisko testowe odpowiada środowisku produkcyjnemu ● Łatwy dostęp do wyników testów oraz ostatniej działającej wersji ● Każdy widzi wyniki ● Automatyczny deployment
- 7. Continuous Integration – Repozytorium kodu ● Wszystkie artefakty są wersjonowane w repozytorium kodu ● Zmiany są commitowane i integrowane jak najczęściej – przynajmniej raz dziennie ● Ilość rozgałęzień w repozytorium powinna być zredukowana do minimum – zmiany powinny być ciągle integrowane.
- 8. Continuous Integration – Automatyczny Build ● Powinna być możliwość zbudowania całego systemu za pomocą jednej komendy. ● Narzędzia takie jak make, ant, maven, nuget, rake, DEB, RPM, MSI mogą okazać się pomocne. ● Automatyzacja budowania oprogramowania powinna zawierać w sobie instalację tego oprogramowania we wspólnym środowisku testowym
- 9. Continuous Integration – Testy Automatyczne ● Każda zmiana powinna być przetestowana za pomocą automatycznych testów. ● Serwer Continuous Integration powinien budować aplikacje, instalować ją w środowisku testowym oraz uruchamiać testy.
- 10. Continuous Integration – Szybki Build
- 11. Continuous Integration – Łatwy dostęp do ostatniej działąjącej wersji
- 14. Test First Development Testowanie to forma dostarczania informacji zwrotnej na temat tego czy i jak testowane oprogramowanie działa. Im szybciej i częściej dostarczana jest informacja o działaniu aplikacji tym bardziej jest ona wartościowa. TFD polega na utworzeniu pętli dostarczającej częstą i trafną informację dla jak najmniejszych wprowadzanych zmian.
- 15. Pętla Test First 1. Napisz test 2. Uruchom test 3. Wprowadź zmianę 4. Uruchom testy
- 16. Test F.I.R.S.T FAST: Testy powinny być szybkie. INDEPENDENT: Testy powinny być niezależne. REPEATABLE: Testy powinny być powtarzalne. SELF VALIDATING: Testy powinny dawać jednoznaczną odpowiedź na temat tego czy oprogramowanie działa. TIMELY: Testy powinny być pisane w odpowiednim momencie.
- 17. Fast Co to znaczy, że test jest szybki? Jeśli testy są zbyt wolne to nie są uruchamiane wystarczająco często.
- 18. Independent Kolejność uruchamiania testów nie powinna mieć znaczenia. Powinna być możliwość uruchomienia każdego testu w odizolowaniu od pozostałych. Jeśli jeden test nie przejdzie wyniki pozostałych nie powinny być od tego zależne.
- 19. Repeatable Bez zmian w funkcjonalności testy zawsze powinny dawać takie same wyniki. Testy powinny być niezależne od środowiska na którym są uruchamiane. Koniec z tekstami: "A u mnie działa".
- 20. Self Validating Testy dostarczają informacji zwrotnej czyli jednoznacznej odpowiedzi na temat tego czy i jak działa wytwarzane oprogramowanie. Informacja o statusie testów nie powinna wymagać żadnej ingerencji testera czy developera.
- 21. Timely Testy powinny być pisane przed kodem produkcyjnym. Odkładanie pisania testów na "po kodzie produkcyjnym" nie ma sensu gdyż wtedy testy już nie są przeważnie nam potrzebne. Pisanie testów po kodzie powoduje, że rosną koszty ich wytworzenia i utrzymania.
- 22. Test-Driven Development Oprócz testów do naszej pętli dodajemy jeszcze projektowanie architektury.
- 23. TDD = TFD + Refactoring TDD opiera się na wytwarzaniu oprogramowania w bardzo małych krokach. W jednym kroku piszemy jeden test i jedną małą funkcjonalność. Nie dotykamy kodu funkcjonalności, gdy nie mamy napisanego testu, który nie przechodzi.
- 24. Pętla TDD
- 25. Dyscyplina Zgodnie z definicją wszystko wydaje się być proste. W praktyce okazuje się, że potrzebna jest bardzo duża dyscyplina by przestrzegać powyższych zasad. Nad własną dyscypliną trzeba wytrwale pracować.
- 26. Dwie podstawowe zasady Piszemy kod nowej funkcjonalności tylko gdy testy nie przechodzą. Usuwamy wszystkie duplikacje na które natrafimy.
- 27. Efekt Każdy pisze testy, gdyż nie ma czasu na czekanie aż ktoś inny zrobi to za nas. Kod tworzony jest na podstawie świadomie podjętych decyzji zasilonych informacją z testów. Każdy nawet najmniejszy element aplikacji jest przemyślany i odpowiednio zaprojektowany. Szybka informacja zwrotna podczas wprowadzania bardzo małych zmian pozwala na łatwe wykrywanie błędów. Architektura wyłania się dzięki bardzo małym krokom i ciągłemu refactoringowi...
- 28. TDD jest przede wszystkim techniką tworzenia specyfikacji i architektury wyłaniającej się. Testy są efektem ubocznym. Testy powstałe przy użyciu TDD to nie wszystko. Dobrze napisane testy są wykonywalną dokumentacją kodu Czym jest TDD
- 29. Wymagania i specyfikacja– czyli to, co testujemy 1. Jaki mamy cel biznesowy? 2. Co chce osiągnąć interesariusz? 3. Jakie możliwości powinien dostarczać nasz produkt by osiągnąć cel interesariusza? 4. Jak ta funkcjonalność ma wyglądać? 5. Jak ta funkcjonalność ma zostać zaimplementowana?
- 31. Behavior Driven Development – User Stories In order to <goal> As a <stakeholde> I want <action>
- 32. Behavior Driven Development – User Stories In order to log in into application As a user I want log in to application
- 33. Behavior Driven Development – User Stories In order to provide limited access to sensitive user data As a registered user I would like to have possibility of authentication In order to have possibility to send SPAM to users As a business owner I would like to have possibility to ask users for their email address
- 34. Behavior Driven Development – User Stories In order to... As a... I would like to...
- 35. Behavior Driven Development – Scenariusze //GIVEN ...kontekst... //WHEN ...akcja... //THEN ...walidacja...
- 36. Page Object Pattern + BDD A teraz... Kodzik...
- 38. Automatyzacja Testów w projektach typu “legacy” ● Legacy Code ● Odwrócona Piramida Testów ● Refaktoring
- 39. Testy End-to-end Testy Funkcjonalne/Integracyje Testy Jednostkowe Jak wygląda oprogramowanie idealne?
- 40. Testy End-to-end Testy Funkcjonalne/Integracyje Testy Jednostkowe Dlaczego więc wygląda to tak?
- 45. Odwaga...
- 46. Testy End-to-end Testy Funkcjonalne/Integracyje Testy Jednostkowe
- 47. Testy End-to-end Testy Funkcjonalne/Integracyje Testy Jednostkowe Tak, jasne...
- 48. Czasami piramida testów wygląda jakoś tak...
- 49. Testy End-to-end Testy funkcjonalne/integracyjne Testy Jednostkowe
- 51. Czas...
- 53. Debugowanie...
- 55. •Piszemy testy end-to-end tylko po to, by umożliwić refaktoryzację kodu na niższych poziomach. •Tworzymy testy jednostkowe •Usuwamy testy end-to- end!