DOMAIN-DRIVEN TESTING

.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns

Pattern Summary

Develop a domain-specific language for testers to use when writing their automated test cases.
The DOMAIN-DRIVEN TESTING Mind Map shows how this pattern relates to its relevant issues and patterns.

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, please add your name and a brief story of how you used this pattern: your context, what you did, and how well it worked - or how it didn't work!

.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns
B2