Sometimes we are working on a new feature in our code and we want to write a specification for it without yet really implementing the feature.
To indicate we know the specification will fail while we are implementing the feature we can add the @PendingFeature annotation to our specification method.
With this annotation Spock will still execute the test, but will set the status to ignored if the test fails.
But if the test passes the status is set to failed.
So when we have finished the feature we need to remove the annotation and Spock will kindly remind us to do so this way.
Continue reading →
When we write a feature method in our Spock specification to test our class we might run into long running methods that are invoked.
We can specify a maximum time we want to wait for a method.
If the time spent by the method is more than the maximum time our feature method must fail.
Spock has the @Timeout annotation to define this.
We can apply the annotation to our specification or to feature methods in the specification.
We specify the timeout value as argument for the @Timeout annotation.
Seconds are the default time unit that is used.
If we want to specify a different time unit we can use the annotation argument unit and use constants from java.util.concurrent.TimeUnit to set a value.
Continue reading →
To ignore feature methods in our Spock specification we can use the annotation @Ignore.
Any feature method or specification with this annotation is not invoked when we run a specification.
With the annotation @IgnoreRest we indicate that feature methods that do not have this annotation must be ignored.
So any method with the annotation is invoked, but the ones without aren’t.
This annotation can only be applied to methods and not to a specification class.
Continue reading →
Although I couldn't make it to Gr8Conf EU this year, I am glad a lot of the presentations are available as slide decks and videos.
The slide deck for the talk Interesting nooks and crannies of Spock you (may) have never seen before by Marcin Zajączkowski is very interesting.
This is really a must read if you use Spock (and why shouldn't you) in your projects.
One of the interesting things is the ability to change the response for methods in a class that is stubbed using Spock's Stub method, but have no explicit stubbed method definition.
Continue reading →
In a previous post we learned that we can check a specific exception is not thrown in our specification with the notThrown method.
If we are not interested in a specific exception, but just want to check no exception at all is thrown, we must use the noExceptionThrown method.
This method return true if the called code doesn't throw an exception.
Continue reading →
In a Spock specification we write our assertion in the then: or expect: blocks. If we need to write multiple assertions for an object we can group those with the with method. We specify the object we want write assertions for as argument followed by a closure with the real assertions. We don't need to use the assert keyword inside the closure, just as we don't have to use the assert keyword in an expect: or then: block.
Continue reading →
In a previous post we saw how can use the Spock configuration file to include or exclude specifications based on annotations. Instead of using annotations we can also use classes to include or exclude specifications. For example we could have a base specification class DatabaseSpecification. Other specifications dealing with databases extend this class. To include all these specifications we use the DatabaseSpecification as value for the include property for the test runner configuration.
Continue reading →
One of the handy features of Groovy is to change the behavior of classes using MOP (Meta-Object Protocol). We change the metaClass property of a class to alter an implementation. You can for example override a static method of a class. See the example below:
Continue reading →
