Speaker: Piotr Kiebasiński Language: Polish Testy jednostkowe traktowane są często przez programistów jako zło konieczne, coś co powoduje opóźnienie przy dostarczeniu oprogramowania albo niepotrzebnie dokłada pracy. Podczas wykładu będę chciał pokazać, że testowanie może mieć sens, być efektywne, zmniejszyć ilość czasu spędzonego nad kodem i wydatnie podnieść zarówno tempo pracy jak i jej jakość. Odwołam się przy tym do metodyki BDD oraz do wykorzystania frameworka Spock. 4Developers: http://4developers.org.pl/pl/

1. Kilka słów o testowaniu dla programistów
czyli o testach, BDD, Spocku i kilku innych
drobiazgach
20 kwietnia, 2015 Warszawa, 4dev
Piotr Kiebasiński

2. Kto jest kim?
Piotr Kiebasiński,
piotr.kiebasinski@j-labs.pl
Absolwent IF UJ, z zamiłowania i wyboru konsultant i
kontraktor w IT
Java, Linux, Bash, Python i parę innych 

3. j-labs competences
• Over 80 engineers in Cracow office
• On market since 2008
• Member of ASPIRE – association of IT and BPO centers
• Main technology areas: Java / JEE, .NET / ASP.NET, QA
• Reliable partner for international organizations

4. Jak to zwykle wygląda na samym początku?
• Nowy pracownik na praktykach -> czyli napisz mi tutaj
testy, bo pokrycie kiepskie 

5. Jak to zwykle wygląda na początku?
•NUDA!

6. Pierwszy porządny bug – czyli NullPointerException
• Tylko że rzadko jest tak:

7. Pierwszy porządny bug – czyli NullPointerException
• Częściej tak:

8. Po co testy?
• Dlaczego pisać testy przy tak prostych błędach?
• Bo pewność
• Bo powtarzalność (automatyzacja)
• Bo refaktoring
• Bo kod żyje dużo dłużej po napisaniu niż nam się wydaje
• Bo można sprawdzić kiedy się zepsuje znowu

9. Pierwszy porządny bug – czyli NullPointerException
• Ale jak to przetestować?
• Czyli skąd wziąć:
• UserDao
• AuthorDao
• I jeszcze być pewnym że zwrócą to co chcemy?

10. Pierwszy porządny bug – czyli NullPointerException
• Metoda I – użyć prawdziwych obiektów i porobić
odpowiednie wpisy w bazie (testy integracyjne)
• Metoda II – czyli zasymulować – zamockować zachowanie
na którym nam zależy
• Mockito, PowerMock, Jmockit etc
• Spock

11. Spock - wprowadzenie
• Link: https://code.google.com/p/spock/
• „Spock is a testing and specification framework for Java and
Groovy applications. What makes it stand out from the crowd is
its beautiful and highly expressive specification language. Thanks
to its JUnit runner, Spock is compatible with most IDEs, build
tools, and continuous integration servers. Spock is inspired from
JUnit, RSpec, jMock, Mockito, Groovy, Scala, Vulcans, and other
fascinating life forms.”

12. Spock - wprowadzenie
• Łatwy do nauczenia –wymaga w zasadzie JUnita
• Stworzony w Groovym - z całym dobrodziejstwem
inwentarza
• Eliminuje niepotrzebną pracę – na przykład pisanie asercji
• Szczegółowe informacje – choćby w opisowych nazwach
metod albo w komunikatach błędów

13. Spock - wprowadzenie
• Nie narzuca metodyki pisania testów
• Czytelny kod – chyba że ktoś się mocno postara
• Elastyczny i rozszerzalny – Spring, transakcje etc – żaden
problem
• Kompatybilny z JUnitem

14. Spock - wprowadzenie

15. Spock - uniezależnienie się od zewnętrznych systemów
• Story: Należy stworzyć mechanizm, który zapisze incydent
w przypadku kiedy w bazie danych mamy problemy z
odświeżeniem się widoku

16. Spock - uniezależnienie się od zewnętrznych systemów

17. Spock - uniezależnienie się od zewnętrznych systemów
• Czemu testy przecież kod jest banalny na oko?

18. Po co testy?
• Dlaczego pisać testy przy tak prostym kodzie?
• Bo pewność
• Bo powtarzalność (automatyzacja)
• Bo refaktoring
• Bo kod żyje dużo dłużej po napisaniu niż nam się wydaje
• Bo można sprawdzić kiedy się zepsuje znowu
• Bo jakość

19. Spock - uniezależnienie się od zewnętrznych systemów

20. Spock - wprowadzenie

21. Spock - wprowadzenie

22. Spock - wprowadzenie

23. Spock - given-when-then-where

24. Po co testy?
• Dlaczego pisać testy w taki sposób?
• Bo pewność
• Bo powtarzalność (automatyzacja)
• Bo refaktoring
• Bo kod żyje dużo dłużej po napisaniu niż nam się wydaje
• Bo można sprawdzić kiedy się zepsuje znowu
• Bo jakość
• Bo porządkuje nam myślenie

25. Spock - given-when-then-where

26. Spock - given-when-then-where

27. Spock - given-when-then-where

28. Spock - uniezależnienie się od zewnętrznych systemów
• Story: Należy stworzyć kontroler obsługujący procedurę
bazodanową liczącą pewne statystyki (duży wolumen
danych) i zwracający w pozytywnym scenariuszu zawartość
pliku. Obsługa błędów w myśl specjalnego dokumentu.

29. Spock - Controller story

30. Spock - Controller story

31. Spock - Controller story

32. Spock - WOW features - podsumowanie
• Mockowanie:
def subscriber = Mock(Subscriber)
• Czytelność
when:
publisher.send("hello")
then:
1 * subscriber.receive("hello")
publisher.messageCount == 1
• where (dopisanie przypadku testowego)

33. Spock - WOW features - podsumowanie
• Wymuszenie porządku
given/when/then
• operacje kolekcjach (vide możliwości Groovego)
[], [:], <<, every
• czytelne asercje
• http://spock-framework.readthedocs.org/en/latest/interaction_based_testing.html

34. Spock - WOW features - podsumowanie

35. Pytania?
Dziękuję za uwagę!