4Developers 2015: Couple of words about testing in Java, Spock and BDD - Piotr Kiebasiński
0 likes216 views
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/
![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](https://image.slidesharecdn.com/piotrkiebasiski-coupleofwordsabouttestinginjavaspockandbdd-150617065351-lva1-app6891/85/4Developers-2015-Couple-of-words-about-testing-in-Java-Spock-and-BDD-Piotr-Kiebasinski-33-320.jpg)
4Developers 2015: Couple of words about testing in Java, Spock and BDD - Piotr Kiebasiński
- 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
- 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
- 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
- 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