Search Here!

Saturday, June 8, 2013

Importance of DSL in Automated Functional Testing

DSL is a specification language that is dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique. The DSL is a software solution that focuses the domain experts to spend their time more effectively describing or solving a problem as opposed to battling with a programming language. Even though this concept has been around for several years, but its implementation in the test automation space, in my opinion, is still in its early stages.
Imagine documenting your test case steps (Specifications) pretty much as you would do in your test case management system but being able to “run” these tests in an automation fashion without any coding! This is the promise that this solution can provide.
There are some tools that allows creating tests as Specifications. FitNesse and Cucumber are two such examples.
The best way to achieve good quality re-useable and robust code base is to create a Domain Specific Language for your test framework. What does it mean in simple words? Let me explain that on an example.
To run a search in your web-based application to check if the expected amount of links is returned, you need to write quite a few lines of code. Most probably you have quite a few similar Test Cases in this area. So the best thing to do is to extract all the global initiatlization functions and common actions to one object called myApplication (you name it) and methods like myApplication. runSearch (searchString, expectedNumeberOfResults, firstLinkOntheList).
When you read that code and write new Test Cases in your IDE, you will learn the structure of the framework and use it naturally. And imagine that some screen or flow changes. If you have lots of independent procedures, you have a maintenance nightmare. With use of DSL, you have to change the code in one spot only and the Test Cases will pass again. You can even leave creating the library to experienced developers and have less technical people to write agile Test Procedures. This way the test automation will be fun and rewarding.

No comments:

Post a Comment