Fork me on GitHub

Thursday, May 8, 2008

Renewed thougths about DRY in Testing

This is in reference to my previous post on DRY and Testing. In that I made a point that DRY as a principle which must be upheld not only for development but also for testing. But there is something special about testing especially tests which distinguish them from development code. Tests are actually examples which everybody uses as guide lines for development. They are executable specification and help people to understand the software. So being used as examples demand expressibility and ease of understandability.

DRY can make code terse and compact for maintenance but when it comes to test code we must compromise some of it for understandability. This I realized when I remembered that tests are not only code but also serve as examples. Brian Marick has an interesting post in this subject in his blog.

I think this is something important I learned. But it is also necessary to keep the balance between the not letting repetition in code and helping tests be as examples.

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.