DOMAIN-DRIVEN TESTING
Pattern Summary
Develop a domain-specific language for testers to use when writing their automated test cases.
Category
Design
Context
This pattern is appropriate when testers should be able to write and run automated tests even if they are not adept with the automation tools, or if you want them to start writing test cases for automation before the Software Under Test (SUT) has been completely developed.
The pattern is not appropriate for very small-scale or one-off automation efforts.
Description
Testers develop a simple domain-specific language to write their automated test cases with. Practically this means that actions particular to the domain are described by appropriate commands, each with a number of required parameters. As example let’s imagine that we want to insert a new customer into our system. The domain-command will look something like this:
| New_Customer (FirstName, LastName, HouseNo, Street, ZipCode, City, State) |
Now testers only have to call New_Customer and provide the relevant data for a customer to be inserted. Once the language has been specified, testers can start writing test cases even before the SUT has actually been implemented.
Implementation
To implement a domain-specific language, scripts or libraries must be written for all the desired domain-commands. This is usually done with a TEST AUTOMATION FRAMEWORK that supports ABSTRACTION LEVELS.
There are both advantages and disadvantages to this solution. The greatest advantage is that testers who are not very adept with the tools can write and maintain automated test cases. The downside is that you need developers or test automation engineers to implement the commands so that testers are completely dependent on their “good will”. Another negative point is that the domain libraries may be implemented in the script language of the tool, so that to change the tool may mean to have to start again from scratch (TOOL DEPENDENCY). This can be mitigated to some extent using ABSTRACTION LEVELS.
KEYWORD-DRIVEN TESTING is a good choice for implementing a domain-specific language: Keyword = Domain-Command
Potential problems
It does take time and effort to develop a good domain-driven automated testing infrastructure.
Issues addressed by this pattern
LATE TEST CASE DESIGN
MANUAL MIMICRY
NON-TECHNICAL-TESTERS
OBSCURE TESTS
TOO EARLY AUTOMATION
Experiences
If you have used this pattern and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.