DSLs have been buzzing around for a while now, and I thought of putting some thoughts together.
DSL – Domain Specific Languages, what does it mean for Testing? What are the benefits..
Over the years automation testing has changed from record and play back mechanism to more structured, framework oriented approach. Benefits were evident Test were readable, Scalable and Maintainable.
But there was more needed to be done, as most automation tests would turn in to over head rather then assets. Framework based approach was good..but came up with its own sets of problem. Some of them were Code like tests, which meant they were not human readable and needed either hours of
documentation to make them explicit to humans. So if the application changed underneath both test and documentation needed to change. And after a while these will not match each other by any means.
Frameworks like keyword driven testing enabled naive to write Tests, however created the problem of highly non abstracted tests.
Since the introduction of methodologies like Agile, it was inevitable that those problem needed to be sorted fast. Tests needed to be changed quickly with often changing requirements.
DSLs allows you to write tests in your own domain..be it banking, Online Gaming or Travel Industry. Which means tests are human readable and highly contextual to domain.
For example – I need to write a Test for a baking application for testing a Scenario of Transfer of a fund from Account A to Account B. Note, I am talking in terms of any specific tool here, and that I will keep up for a separate post.
<Test>
- Login in my online banking application with user “A”
- Go to transfer funds page
- Check initial balance it should be “£ 500″
- Transfter amount “£100″ to account “B”
- Check final balance , it should be “£ 400″
- logout from the application.
</Test>
In above example , Test exactly looks like manual test scripts but there nature is Executable in whatever technology and tool we choose.
What problems does it solve?
- Maintenance is easier now as test are human readable.
- Adding and Amending a step in Test just requires finding the right step, rather then changing the implementation (In Most of the cases).
- For example – In above Test I need to add a new requirement of a welcome page after login. We simply introduce another DSL step after step1 “Verify user is shown welcome page with him name on it”, and rest of the test is still unchanged.
- Test can be extended easily to do more comprehensive end to end test.
- If the application changes underneath in terms of UI Objects , tests will remain unchanged, only the underlying implementation will change.
- If a business process changes completely, changed can be accommodated easily by changing the DSL definition. For example in above Test the transfer process changes and now required another level of authentication before transferring the funds. We would change the definition of Step4 to ‘Transfter amount “£100″ to account “B” and enter authentication password for user “A”‘
DSLs can also come with its own challenges, which I would like to discuss in my next post.
[quicksubscribe]
