Fork me on GitHub

Tuesday, April 22, 2008

DRY and Testing projects

As an agile developer a lot of practices figure into my way of working like pairing, refactoring, TDD (Test Driven Design or Development. I prefer design.) Of all these practices the one which the most important, often mistaken to be the simplest and has definitive effect is DRY short for Don't Repeat Yourself.

The basic principle is to remove any kind of duplication in any kind of knowledge. But the catch which most people fail to get is it is not only with the code. We should not have duplication in code, data, tests, configuration, environment setup and tear down and even documentation. It is a well known fact that duplications will increase the maintenance effort of the code, lead to logical inconsistencies and poor factoring.

As a person with role of developer in a automation testing team, I have a chance to see a lot of people writing a lot of code. One of the sad things which I notice most often is when writing test code people tend to leave out practices like DRY or refactoring. The reason may partially be they are not familiar or they tend to think test code is write and throw away code, a trend partially encouraged by GUI recorders or code generators. I got the idea of writing this article from the experience I got from a pairing session with my friend while writing some code in WATIR.

We have a hybrid driven framework for WATIR internally used with in the company. One of the aspects of the framework is its ability to create a suite by selecting test cases from excel sheet. They have used three different workbooks for this purpose. One for creating the business flow from individual business components, one for the suite creation and other for the test data. The problem is there is duplication of test cases between the business flow sheet and the suite selection sheet. When I pointed out to my friend his instant reply was it was not in the code and so its not a problem. This was pretty odd to me and I explained to him that even though the test cases are low now, it is twice the job when we need to update something. And also if the test cases increase the work becomes even more difficult. So we moved the suite controlling as well as business flow to a single sheet. This removed the duplication we had as well as the maintenance attached with it.

The duplication here is subtle but these are the places we usually miss until it grows to a larger problem. Most of the time we concentrate on code and miss out to make our test data, environment, configuration, build scripts, test code DRY. I tend to see a lot of testers tend to write code for testing but fail to understand that tests are also code which need to be maintained. This leads to brittle test code and throw away test code which has data hard coded, code duplicated, non refactored. It is difficult to maintain such code and it is an over head to throw away it.

DRY is one of the most important principles of Agile because it helps to create a design which has maintainability in built to it. It is important to realize its importance and try to refactor our work at regular intervals to reduce duplication where ever it is and what ever code it may be.

No comments: