Orientate your tests towards the business domain
|
Domain Oriented Testing (DOT) is “domain oriented” because everything within it is oriented towards the business domain model. The tests, in turn, are mostly component-level and are driven from your user stories. You can also have unit tests that are driven by the needs of the code, but these are massively de-emphasized. The idea is to bake error handling and corner cases into your code from the ground up, by focusing on "unhappy path" scenarios as you write your tests - and to focus on requirements coverage in preference to code coverage. |
In other words: test behaviour, not your implementation.
DOT is designed to work well with Scrum, Parallel Agile (PA), Kanban... in fact just about any kind of project, as long as there's some form of requirements (be it agile user stories, use cases, features, a functional requirements specification or whatever) that can be expanded into "happy path" and "unhappy path" scenarios.
30,000ft Overview
DOT is a set of practices operating at three levels (acceptance, component and unit testing).
Its chief focus is on the business domain: you model domain entities, events etc in your tests and system under test, with a real emphasis on exploring “unhappy path” scenarios from the outset.
Error handling and alternate scenarios are then factored into your design from the beginning, rather than tacked on as an afterthought or as a series of reactions to bug reports.
Essentially, DOT can be implemented in your project as:
| Acceptance tests | <- |
BDD and contract-based tests | |
| Component tests | <- | “personal BDD” - code-level, story-driven |
|
| Unit tests | <- | TDD - code-driven |
... all wrapped in Domain Driven Design (DDD). As a technique for exploring the domain, event storming works particularly well here, as the events and boundaries feed directly into the tests.
DOT provides guidance on combining the three levels of testing efficiently and to good effect. It also provides specific guidance at each of the 3 levels.
What's Next for DOT?
DOT is featured in the upcoming book Parallel Agile by Barry Boehm, Doug Rosenberg and Matt Stephens (that's me)... and will have its own book called, you guessed it, Domain Oriented Testing, filled with decades' worth of hard-won experience developing and testing complex software projects.
The DOT book is due out in mid 2020 or therabouts. The book is still a work-in-progress, so that's likely to vary somewhat!
How to stay up-to-date with the latest DOT developments:
| |
Read articles about DOT - and about testing/software engineering in general - over on Medium |
| |
Follow me on Twitter for opinionated thoughts (and thoughtful opinions) on software engineering and testing |
| |
Join the LinkedIn group - this is the best place to ask questions about DOT, and to get to know other people interested in this new software process |
| Interested to know when the book is nearing publication? Be the first to know by joining the mailing list (guaranteed non-spammy) |
More details about DOT coming soon... stay tuned!
- Matt Stephens