Chapter 8. Testing DSLs
In this chapter
- Why create testable DSLs?
- Approaches for building testable DSLs
- Building a Testing DSL
- Integrating the Testing DSL with a unit-testing framework
The reasons for creating testable systems have been debated elsewhere for years, so we won’t go over them again here. It’s well accepted that testable and tested systems have lower maintainability costs, are easier to change and grow, and generally are more effective in the long run. I have a high regard for testability, and I consider it a first-level concern in any application or system that I build.
Unlike most systems, a DSL isn’t a closed environment. DSLs are built explicitly to enable greater openness in the environment. It’s almost guaranteed that your DSL will be used in ways that you can’t predict. To ensure that you can grow the language as needs change, you need to know what can be done with your language in the first place, and ensure that you have tests to cover all those scenarios.
It’s hard to find breaking changes (or regression bugs) in a language. We tend to ignore the possibility of bugs at the language level, so it’s doubly hard to track them down.