Existing Groovy DSLs
[ 242 ]
The common language of ATDD and BDD revolves around defining behavior in
user-centric terms. Whether we are writing acceptance tests or defining behavior,
we end up using terms such as given, when, and then as follows:
- Given a precondition
- When certain actors perform certain actions
- Then we expect a predetermined result
Of course, this type of terminology is ripe for using a mini-language or DSL to define
the tests or behavior. And this is exactly what is happening. There are a plethora of
BDD style testing frameworks out there already, the most notable being RSpec,
a BDD-style framework implemented by using Ruby's dynamic features.
Spock
We have been using Spock BDD style syntax throughout the book to illustrate
the code examples. So, you are already well familiar with the given/when/then
semantics of BDD. I hope that using this syntax has brought clarity to the code
examples. In effect, the Spock DSL has become part of the primary narrative of
the book.
In Chapter 3, Essential Groovy DSLs, we took a detailed look at how to use Spock.
Now, we will take a look at how some of the DSL-like features of Spock are
implemented. First, let's recap on some key elements of a Spock specification.
For the purpose of this chapter, we will just focus on feature methods and blocks:
- Fixture methods: Fixture methods are to set up and teardown test data,
that is, setup(), cleanup(), setupSpec(), and cleanupSpec(). - Feature methods: A feature method in Spock is used to describe a single
test scenario. It can have any valid Groovy method name, but typically
by conventions, we use the Groovy; string as method name syntax, so the
method name also becomes part of the test documentation. The thing that
separates feature methods from other methods in Spock is the fact that they
contain blocks. - Blocks: Blocks in Spock are the given, when, and then clauses of the BDD
semantics. They are denoted by an equivalent Groovy label, for example,
given:, when:, then:, followed by an optional descriptor string and any
number of code statements. The block is terminated by the next valid block
or at the end of the enclosing feature method. - Helper methods: Any method that is not a fixture method or does not
contain any valid blocks is considered to be a helper method.
http://www.ebook3000.com