Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

4Developers 2015: Couple of words about testing in Java, Spock and BDD - Piotr Kiebasiński

182 views

Published on

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/

Published in: Software
  • Be the first to comment

  • Be the first to like this

4Developers 2015: Couple of words about testing in Java, Spock and BDD - Piotr Kiebasiński

  1. 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. 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. 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. 4. Jak to zwykle wygląda na samym początku? • Nowy pracownik na praktykach -> czyli napisz mi tutaj testy, bo pokrycie kiepskie 
  5. 5. Jak to zwykle wygląda na początku? •NUDA!
  6. 6. Pierwszy porządny bug – czyli NullPointerException • Tylko że rzadko jest tak:
  7. 7. Pierwszy porządny bug – czyli NullPointerException • Częściej tak:
  8. 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. 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. 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. 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. 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. 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. 14. Spock - wprowadzenie
  15. 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. 16. Spock - uniezależnienie się od zewnętrznych systemów
  17. 17. Spock - uniezależnienie się od zewnętrznych systemów • Czemu testy przecież kod jest banalny na oko?
  18. 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. 19. Spock - uniezależnienie się od zewnętrznych systemów
  20. 20. Spock - wprowadzenie
  21. 21. Spock - wprowadzenie
  22. 22. Spock - wprowadzenie
  23. 23. Spock - given-when-then-where
  24. 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. 25. Spock - given-when-then-where
  26. 26. Spock - given-when-then-where
  27. 27. Spock - given-when-then-where
  28. 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. 29. Spock - Controller story
  30. 30. Spock - Controller story
  31. 31. Spock - Controller story
  32. 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. 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. 34. Spock - WOW features - podsumowanie
  35. 35. Pytania? Dziękuję za uwagę!

×