Fork me on GitHub

Wednesday, May 7, 2008

Acceptance Test Driven Development of DSL

Domain Specific Languages have been very popular lately as a way of abstraction and a lot of talks have been going on about the different forms of DSLs and their role in helping communicating the intent more clearly. To have a quick introduction of DLSs take a look at the wiki entry on DSLs or entry by Martin Fowler in his bliki. ]

This is my experience about designing DSL as I have been involved in working on a fluent interface. It is a based on WATIR to facilitate testers to write more expressive scripts and we are planning to make it open source soon. The most important problem we quickly ran into when me and my friend started developing this was unable to decide what would be the best way to represent this interface. So we thought we would create a basic set of interfaces and based on the initial design we will start developing and refactor the initial set if we feel we can do better. But still we wanted to make it more effective by involving more people. So we thought it would be fun if we could try out the acceptance test driven approach for the development of this DSL.

We got a set of people interested in this and having them as customers we worked out the initial set of fluent interfaces as acceptance tests. Then we started with our development of the interfaces. As and when the people wanted to make the interfaces better or add anything new we have a discussion and once we reached a satisfactory and update the acceptance tests. As the acceptance tests guided us through the process and helped us to visualize the usage of the DSL as well was written from the customer's perspective the DSL was a success with in our company.

The most valuable lesson we learned from this was for the DSL development using customers i.e. the domain experts as the designers is most important and coding the usage of DSL as an acceptance test acts as a guide map or example for the development for the DSL. As the acceptance test models the usage we could also improve the interfaces if needed by seeing them in the tests.

If you have any thoughts related to the design of DSL and ATDD I welcome your comments.

No comments: