Domain Specific Testing Languages
Domain Specific Testing Languages (DSTLs) express customer requirements as tests with the scope, granularity, and transparency you need. Dynamically extensible DSTLs help you keep the core testing tool simple while creating automated test scripts the customer can easily read, verify, and use as requirements documents. In this session, you’ll get practical tips to foster test code re-use and reduce test maintenance costs, especially on large and long-running projects. Learn to use “refactor into abstraction” and “intentional testing” as two complementary paradigms for making stronger, more expressive, more maintainable tests.
Script-based automated testing tools suffer from challenges in scope, granularity, transparency, and customer comprehensibility. Domain Specific Testing Languages (DSTLs) allow developers and customers to express tests in customer language and at appropriate granularities of abstraction. Support for dynamic extension of DSTLs facilitates both bottom-up abstraction (refactoring tests for maintainability and emergent order) and top-down abstraction (“intentional testing”, by analogy to intentional programming).
Automated tests written in dynamically extensible DSTLs are easily readable by the business people that help to specify them, since they are written in the customer’s business terms. Subject matter experts can assist in verifying the test content (process flow and expected outcomes), and can use the test script as a requirements document, in addition to its use as executable requirements for the developers.
No out-of-the-box testing tool can support all levels of abstraction, the terms of art for all domains, and the specific nuances of meaning that vary between customers. By providing configurable and extensible support for domain-specific testing languages, testing tools projects can keep the core testing tool simple and yet provide this level of power to all users of the testing tool.
A preliminary version of this session was presented at Agile2007, and an updated version will be presented in March at SD West 2008.
In response to feedback from last year’s session, we are broadening the set of script-based automated testing tools from which we draw our examples, and adding sections covering test abstraction, “intentional testing”, and practical tips for bottom-up abstraction (which augments test code re-use and reduces test maintenance costs, especially on large and long-running projects). We will begin with a discussion of what a DSL is, and thus what a DSTL is. We will look at how abstraction granularity presents a challenge to test writers, and how dynamically extensible DSTLs provide a solution. We will offer some examples (drawn from real-world experience) of reducing test complexity and increasing customer visibility into the semantics of tests. We will then introduce “refactor into abstraction” and “intentional testing” as two complementary paradigms for making stronger, more expressive, more maintainable tests, and will show how support for dynamic DSTL definition facilitates both types of abstraction.