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