Please use this identifier to cite or link to this item:
|Lessons learnt from using DSLs for automated software testing
|Computer programs -- Testing
Domain-specific programming languages
Autonomous distributed systems
|Institute of Electrical and Electronics Engineers Inc.
|Micallef, M., & Colombo, C. (2015). Lessons learnt from using DSLs for automated software testing. 8th IEEE International Conference on Software Testing, Verification and Validation Workshops, Graz. 1-6.
|Domain Specific Languages (DSLs) provide a means of unambiguously expressing concepts in a particular domain. Although they may not refer to it as such, companies build and maintain DSLs for software testing on a day-to-day basis, especially when they define test suites using the Gherkin language. However, although the practice of specifying and automating test cases using the Gherkin language and related technologies such as Cucumber has become mainstream, the curation of such languages presents a number of challenges. In this paper we discuss lessons learnt from five case studies on industry systems, two involving the use of Gherkin-type syntax and another three case studies using more rigidly defined language grammars. Initial observations indicate that the likelihood of success of such efforts is increased if one manages to use an approach which separates the concerns of domain experts who curate the language, users who write scripts with the language, and engineers who wire the language into test automation technologies thus producing executable test code. We also provide some insights into desirable qualities of testing DSLs in different contexts.
|Appears in Collections:
|Scholarly Works - FacICTCS
Files in This Item:
Items in OAR@UM are protected by copyright, with all rights reserved, unless otherwise indicated.