Domain-driven testing is part of Design patterns. 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.

Testers develop a simple domain-specific language to write their automated test cases. Practically this means that actions particular to the domain are described by appropriate commands, each with some required parameters. As an 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 been implemented.

#serverless #continuous testing #test driven development #testing