Strategie automatyzacji testow

Strategie Automatyzacji Testów
Wiktor Żołnowski
www.agileszkolenia.pl
facebook.com/CodeSprinters

Automatyzacja Testów w projektach typu “green field”
● Piramida Testów
● Continuous Integration
● Test-Driven Development
● Behavior-Driven Development
● Continuous Delivery

Testy End-to-end - ~10%
•Testy funkcjonalne - ~20%
•Testy Jednostkowe - ~70%
Piramida Testów

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

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.

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

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.

Continuous Integration – Szybki Build

Continuous Integration – Łatwy dostęp do ostatniej
działąjącej wersji

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.

Pętla Test First
1. Napisz test
2. Uruchom test
3. Wprowadź zmianę
4. Uruchom testy

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.

Fast
Co to znaczy, że test jest szybki?
Jeśli testy są zbyt wolne to nie są
uruchamiane wystarczająco
często.

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.

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

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.

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.

Test-Driven Development
Oprócz testów do naszej pętli
dodajemy jeszcze projektowanie
architektury.

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.

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

Dwie podstawowe zasady
Piszemy kod nowej funkcjonalności tylko gdy testy nie przechodzą.
Usuwamy wszystkie duplikacje na które natrafimy.

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

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

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?

Behavior Driven Development – User Stories
In order to <goal>
As a <stakeholde>
I want <action>

In order to log in into application
As a user
I want log in to application

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

In order to...
As a...
I would like to...

Behavior Driven Development – Scenariusze
//GIVEN
...kontekst...
//WHEN
...akcja...
//THEN
...walidacja...

Page Object Pattern + BDD
A teraz... Kodzik...

Automatyzacja Testów w projektach typu “legacy”
● Legacy Code
● Odwrócona Piramida Testów
● Refaktoring

Testy End-to-end
Testy Funkcjonalne/Integracyje
Testy Jednostkowe
Jak wygląda oprogramowanie idealne?

Testy End-to-end
Testy Jednostkowe
Dlaczego więc wygląda to tak?

Testy End-to-end
Dług techniczny...

Dlaczego automatyzujemy testy?

Testy End-to-end
Testy Jednostkowe

Testy End-to-end
Testy Jednostkowe
Tak, jasne...

Czasami piramida testów wygląda jakoś tak...

Testy End-to-end
Testy funkcjonalne/integracyjne
Testy Jednostkowe

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

Wiktor Żołnowski
www.agileszkolenia.pl
http://blog.testowka.pl
facebook.com/CodeSprinters
wiktor.zolnowski@gmail.com

Strategie automatyzacji testow

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Strategie automatyzacji testow

Ähnlich wie Strategie automatyzacji testow (20)

Strategie automatyzacji testow