Chapter 9[ 241 ]GORM as a DSL
We've only scratched the surface of what can be done with GORM and Grails. For
a more comprehensive view of GORM, take the time to look at the Grails reference
at http://www.grails.org. What is most interesting about GORM in relation to
this book is how it achieves its goals through a suite of mini DSLs implemented in
Groovy. Domain classes could be designed and written by a database architect who
can also be insulated from the intricacies of the Groovy language.
Spock as a DSL
Test-driven development (TDD) has become an essential capability for software
developers over the past decade. TDD can mean different things to different
organizations. It can mean the adoption of a full-blown test first style of coding,
where unit tests are written before any functional code. It could just mean that you
write extensive unit tests for every piece of functional code in the system. It may or
may not mean the use of continuous integration builds that run a battery of unit tests
after each code check in. Whatever TDD means to your organization, the chances
are that flavors of xUnit test frameworks, including JUnit, WEBUnit, and HTTPUnit
have been essential tools in your software developer's arsenal for some considerable
time now.
The problem with xUnit-style testing is that these are all tools that are designed by
programmers, for programmers. Your QA staff might be familiar with running xUnit
tests and reporting on problems that they encounter, but they are less likely to be
involved in originating the code tests with these frameworks. Unit tests tend to be
written to test features at the class and method level rather than testing the intended
behavior of the software.
Two alternate models of testing—acceptance test-driven development (ATDD)
and behavior-driven development (BDD)—have been advocated, primarily
within the agile community, as a solution to this issue. The key to promoting
ATDD and BDD is the creation of tools that allow all of the stakeholders, including
developers, business analysts, and QA, to be able to use a common tool with a
common language. Testing begins with a specification of the intended behavior
for the software, which will be entered into the tool. This implies being able to
develop a specification in a language that can be written and understood by of
all the stakeholders, and not just the developers.