Codemotion 2015 spock_workshop


Published on

Diapositivas del taller de Spock usadas durante el codemotion 2015 en Madrid

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Codemotion 2015 spock_workshop

  1. 1. Workshop SPOCK: Testing (in the) Enterprise! Fernando Redondo @pronoide_fer
  2. 2. Roadmap
  3. 3. Whoami • Pronoide’s owner and manager • Currently working for Hybris (SAP) as technical trainer • Java & Friends trainer for last ten years • Doing things with Java from 1999 on • Computer Engineer • Happily married and proud father of two children • Not that Trekky yet (Sure!)
  4. 4. Brief introduction • Groovy based testing and specification framework • Can test anything that runs inside the JVM (even Java code) • Beautiful and highly expressive specification language • Compatible with most IDEs, build tools, and continuous integration servers (JUnit runner)
  5. 5. Terminology and definitions • Spock lets you write specifications that describe expected features (properties, aspects) exhibited by a system of interest. • The system of interest could be anything between a single class and a whole application, and is also called system under specification (SUS). • The description of a feature starts from a specific snapshot of the SUS and its collaborators; this snapshot is called the feature’s fixture. Brief introduction
  6. 6. How do I start with Maven? -
  7. 7. How do I start with Gradle?
  8. 8. Hands on! Before start, you have to… 1. Start Groovy/Grails Tool Suite 3.6 (GGTS) and create a workspace (remember to run it with a JDK and install the gradle extension for eclipse). Groovy 2.4 compiler as well. Or just use gradle and a test editor. 1. Download and unzip it into workspace folder. 2. Hold on! Please wait me right here…
  9. 9. Stage I: Import the workshop project i. Import gradle Project (enterprise.mission)
  10. 10. Specifications Test classes are known as Specifications • All specifications (Specs) must extend from spock.lang.Specification • Each specification must have at least ONE test method, all of these are called feature methods • The most simple assert within a feature method is the expect block, all its sentences must be evaluated to true so that the feature will be OK
  11. 11. A very simple specification Specifications
  12. 12. Stage II: Creating Specs Complete the following specification and acomplish the challenges (org.startrek.challenges.n01.RacesSpec)
  13. 13. Did you get it right? ( Stage II: Creating Specs
  14. 14. Stage II: Creating Specs • Run the spec class as JUnit test • Or execute the test gradle task (gradle quick task launcher)
  15. 15. Specfication methods Within any specification we can found: • Feature methods (or test methods) with diferent blocks of code for stating the scenario under spec • Fixture methods that will be called automatically before or after any single feature methods or before and after the specification: o setup, cleanup, setupSpec and cleanupSpeck • Helper methods that can be called at any time from other methods and can be convenient for code clarity and code reuse
  16. 16. Stage III: Inside the Specs Complete the following specification and acomplish the challenge (org.startrek.challenges.n02.VoyageSpec)
  17. 17. Stage III: Inside the Specs This is not rocket science (
  18. 18. Feature method blocks Inside any feature method we can come across different kinds of phases or blocks: • setup and/or cleanup, at most once per spec, to inicialise and dispose stuff for that particular feature (don’t mix up with fixtures). The setup block can be omitted or aliased with given for readability purpouses. We can create kind of different given sections with and • An expect block may only contain conditions and variable definitions. It is useful in situations where it is more natural to describe stimulus and expected response in a single expression
  19. 19. Stage IV: Inside the feature Complete the following feature methods and probe your courage (org.startrek.challenges.n03.SpaceshipSpec)
  20. 20. Easy peasy!! ( Stage IV: Inside the feature
  21. 21. Feature method blocks These are the kinds of blocks within a feature method (continuation): • when and then blocks always occur together. They describe a stimulus and the expected response – when blocks can contain arbitrary code – then blocks are restricted to conditions, exception conditions, interactions, and variable definitions (which means more options available than for expect blocks) – There can be multiples pair ocurrencies when/then within a feature
  22. 22. Stage IV: Inside the feature Fill in the next feature method if you dare! (org.startrek.challenges.n03.StarfleetSpec)
  23. 23. It was piece of cake!! ( Stage IV: Inside the feature
  24. 24. Feature method blocks These are the kinds of blocks (cont.): • A where block always comes last in a feature method, and cannot be repeated. It is used to write data-driven feature methods. As a matter of convenience it can be written in two different ways: – A row per variable with the << symbol – A column per variable with the | symbol • A data-drive feature method can also be annotated with @unroll – the method will be invoked multiple times with the provider data variables – these can be used in the method description with placeholders (#) – For each iteration the placeholders are replaced with correct values
  25. 25. Stage IV: Inside the feature Things get tougher! (org.startrek.challenges.n03.WeaponsDamageSpec)
  26. 26. As easy as pie!! ( Stage IV: Inside the feature
  27. 27. Testing exceptions In order to deal with specification that throw or not exceptions, Spock provides the following exception conditions • thrown(ExceptionClass) and notThrow(ExceptionClass) • It’s also possible to get the exception instance, to access its attributes: def ex=thrown() Or ExceptionClass ex=thrown()
  28. 28. Stage V: Exception Conditions Complete these features (org.startrek.challenges.n04.DestructionSpec)
  29. 29. Keep it up! ( Stage IV: Inside the feature
  30. 30. Interaction-based testing is a design and testing technique that focusing more on the behavior of objects rather than their state, it explores how the object(s) under spec interact, by way of method calls, with their collaborators • We need to mock the collaborator implementations via def colaborator=Mock(Class) Or Class colaborator=Mock() • Mocks are usually created using Dynamic Proxies or CGLib • We can track interactions with collaborators within then block: when: spock.teletransport() then: 1 * transporter.use() Interactions
  31. 31. Stage VI: Interactions Write down this feature method (org.startrek.challenges.n05.ShipManagementSpec) Clue:
  32. 32. It’s not that complicated, is it? ( ShipManagementSpec) Stage VI: Interactions
  33. 33. Useful stuff In our daily life with Spock, we´ll make use of: • Share objects among feature via @Shared class attributes, other way they won’t share them • There are two kinds of conditions to validate a feature: Implicit and Explicit. Implicit conditions appear within expect and then blocks. To use conditions in other places, you can use assert keyword • Sometimes feature methods are large or contain duplicated code. It can make sense to introduce helper methods • Specifications as Documentation, Spock provides a way to attach textual descriptions to blocks When: “everything start” • You can leverage the use of Hamcrest matchers (assertThat is aliased just as that or expect)
  34. 34. Stage VI: Other mechanisms In the following spec identify with a comment which mechanisms are used (org.startrek.challenges.n06.MoviesSpec)
  35. 35. No brainer ( MoviesSpec) Stage VI: Other mechanisms
  36. 36. Extensions Spock offers lots of functionality for specs. But, there is always a time when something else is needed. Spock provides an interception-based extension mechanism. Extensions are activated by annotations called directives. These are some directives: • @Timeout Sets a timeout for execution of a feature or fixture • @Ignore Ignores a feature method • @IgnoreRest Ignores all feature methods not carrying this annotation • @IgnoreIf To ignore a feature method under certain conditions • @FailsWith Expects a feature method to complete abruptly • @Requires To execute a feature method under certain conditions • @Stepwise executes features in the order that they are declared • @Title and @Narrative To attach a natural-language name to a spec • @Issue indicates that a feature/spec relates to one/more issues in an external tracking system • @Subject To indicate one or more subjects of a spec • Many more! and you can also create your own ones…
  37. 37. Extensions The Spock Spring extension allows Spock to integrate with Spring's TestContext framework • the extension uses Spring API • change add dependencies to our build.gradle: spock-spring, spring-context and spring-test
  38. 38. Stage VI: Extensions Let’s leave that for another time… ;)
  39. 39. Extra ball: Geb! Geb is a framework for automatization of functional web testing. It is based on the following technologies: • Groovy Language (and it’s incredible with Spock) • Selenium WebDriver • JQuery CSS Content Selector • Page Object Model To leveage it, we have to • change add dependencies to our build.gradle: testCompile 'org.gebish:geb-spock:0.10.0' testCompile "org.seleniumhq.selenium:selenium-chrome-driver:2.43.1” • Download and configure our driver (automated browser) in src/test/resources/GebConfig.groovy
  40. 40. Create a simple driver configuration & download the driver (src/test/resources/GebConfig.groovy) Extra ball: Geb!
  41. 41. Let’s perform a search for apock in (org.startrek.challenges.n07.WebNavigationSpec.groovy) Extra ball: Geb!
  42. 42. That was great! But, Can YOU do it in a better way? Extra ball: Geb!
  43. 43. Let’s keep it simple an reusable! Functional Spec. ( Extra ball: Geb!
  44. 44. Let’s keep it simple an reusable! Reusable Page Model. ( MemoryAlphaPage.groovy and MemoryAlphaResultsPage.groovy ) Extra ball: Geb!
  45. 45. And that’s it. Thanks! @pronoide_fer