Słówka ze Spock tutorial

Creating a test in Spock takes less time than using its standard equivalent

These operations can be accomplished by really simple code, hence they do not veil test’s logic

These operations can be accomplished by really simple code, hence they do not veil test’s logic

Spock enforces developers to arrange their tests in BDD

Taking all into consideration I gather that tests created in Spock tend to be more informative, better arranged and easier to understand for other developers

Spock has turned testing into an extremely pleasant and rewarding experience

Please take notice how clear a declaration of a test in Spock is

First of all we want to specify the context within which we would like to test a functionality

The latter one is particularly interesting as it allows to create an extremely tiny tests

In Spock we can distinguish three classes that are able to override a behaviour of some other class or interface: Stubs, Mocks and Spies

In this section we will focus on Stubs as unlike two others imitating other classes is their only responsibility

Nevertheless the syntax for imitating behaviour is the same for all three classes, hence everything shown here will work the same way with Mocks and Spies

If we want to specify some side effect as the result of method invocation...

Let’s elaborate a little on the problem that was raised in the previous example

Let’s assume that this exception should be only thrown when the user with name Michael is being saved

Using mocks has one drawback though that we have to be aware of

By far, you should have figured out from previous examples how to verify whether a certain type of exception has been thrown during the execution of a test

To impose the execution of tests in the order in which they appear in class file we need to annotate a class with a @Stepwise annotation

Spock tries to enhance the way you write tests, providing you with means to make them more descriptive and as easy to read as stories

I always strive to make as descriptive test as possible

Apart from section labels like given, when, then there is also a label and that can be used to split former labels into groups of related statements

In my current project I often come across classes which responsibility is to filter out invalid inputs.

As I do not want to list all the conditions in a test name I try to come up with some business definition that would suggest others what is necessary in the particular scenario for positive validation