- Set up the "smarter-testing-with-spock" project
a. Clone [email protected]:spockframework/smarter-testing-with-spock.git. Or, if you don't have Git installed, download and extract the zipball from https://github.com/spockframework/smarter-testing-with-spock (look out for the 'ZIP' button).
b. Open a console and cd into the project directory. Execute
./gradlew build
(Windows:gradlew build
). If the build passes, you are all set. If it fails, speak up. :-) c. (optional) Generate an IDEA project with./gradlew idea
(Windows:gradlew idea
). Open the project in IDEA. d. (optional) Generate an Eclipse project with./gradlew eclipse
(Windows:gradlew eclipse
). Import the project into Eclipse ("Import -> Existing Projects Into Workspace"). Note: For this to work, you need to have Groovy-Eclipse installed, including its Groovy 2.0 compiler support. For installation instructions, visit http://groovy.codehaus.org/Eclipse+Plugin.
- Write a spec for the
java.util.Stack
class a. Name the specStackSpec.groovy
b. Experiment with different ways of setting up the Stack class (field initializer,setup()
method, implicit/explicitsetup:
block) c. Use self-explaining method names d. Consider a few different initial states (empty stack, stack with single element, stack with multiple elements). If you like, use a separate spec per initial state. Note that you can have multiple specs in the same file. e. Describe a few error conditions. Use thethrown
method to describe expected exceptions. f. Use theold
method to describe how an operation changes the contents of the stack. g. Change one of the spec methods to use given-when-then style. Annotate the blocks with descriptions (e.g.when: "an element is added"
). h. Experiment with a @Shared stack.
- Enhance StackSpec by using data-driven testing for some of its methods a. Try to cover additional interesting cases that you didn't cover in 1. b. Use data pipes to provide the data. c. Refactor the data pipes to a data table. Use || to set apart inputs and outputs. d. Put @Unroll on a method/class to see which iteration(s) fail. e. Add an @Unroll naming pattern to see which inputs made the test fail. f. Write a test that generates data instead of hardcoding it in a data table.
- CodeMaker Workshop
a. Fill in the methods in exercise/CodeMakerSpec.groovy
and describe the interactions between a CodeMaker
(the class under specification) and a Workshop
(the collaborator). The latter classes are declared in exercise/CodeMaker.groovy
.
b. Introduce a few bugs into how CodeMaker
interacts with Workshop
. Execute the spec and study the failure messages.
- Experiment with some of Spock's built-in extensions
a. Use @Ignore to ignore a single method/class.
b. Use @IgnoreRest to ignore all but the annotated methods.
c. Try @Ignore and @IgnoreRest together with spec inheritance (e.g. ignore a method in a base class).
d. Write a test that sleeps for a while and give it a (shorter)
@Timeout
. Observe how the test gets stopped after the timeout has elapsed. Modify the test so that it swallows the first fewjava.lang.InterruptedException
s and keeps sleeping. Observe how it eventually gets stopped. Verify that methods with a@Timeout
annotation run in the same thread as methods without such an annotation. e. Write a class whoseclose()
method throws an exception. Create two instance in the spec and annotate them with@AutoCleanup
. Verify thatclose()
gets called for both of them. Renameclose()
todispose()
and adapt@AutoCleanup
accordingly. f. Write a spec whose methods simulate testing the individual parts of a workflow (e.g. "user logs in", "user adds item to shopping cart", etc.). It's good enough if the methods print out what their part is. Annotate the spec with @Stepwise. Observe that the methods gets exercised in the declared order. Try to run just a single method (don't choose the first one).
-
Experiment with Spock's configuration options a. Create
.spock/SpockConfig.groovy
in your user home directory b. Configure Spock not to filter stack traces c. Create a few annotations and tag some spec methods/classes with them. Try to include/exclude the tagged methods/classes. d. Write a spec containing methods that always pass, always fail, and sometimes fail. Some of the methods should take some time to complete. EnableoptimizeRunOrder
and observe how Spock varies the run order of methods over time. -
Experiment with the spock-example project a. Clone [email protected]:spockframework/spock-example.git or download and extract its zipball from https://github.com/spockframework/spock-example (look out for the "ZIP" button) b. Take a look at the Gradle, Maven, and Ant builds and experiment with them
-
Get familiar with Spock documentation a. Browse the old (http://wiki.spockframework.org) and new (http://docs.spockframework.org/en/latest/) Spock documentation