Decoupling test-data from your test-code

[textile]I won't claim to be a practitioner of unit testing, however, since Test Driven Development started to be adopted I have advised developers on testing approaches and adapted them to unit testing. In his article, "XP Reflections":http://www.testingreflections.com/node/view/738 , Dave Chaplin, an experienced developer and practitioner of TDD writes...

TDD aligns itself with the best practice of 'Test Automation'. Basically, do lots of testing, do it often, and make it darn quick to do. This then ensures it is fast, exhaustive and 100% repeatable... So, whilst TDD is new in terms of its branding, essentially it just brings the best practice of Test Automation to the development level. We all should have been doing this for years anyhow! - Dave Chaplin (Developer)

As a signatory to the "Context Driven School":http://www.context-driven-testing.com/ I wouldn't use the term "Best Practice" but what I would say is that there are some "Almost Always Good Practices" in test automation. One "Almost Always Good Practice" is to de-couple your test-data from your test-code - i.e. Data Driven Testing (DDT) Why?... The key benefit is maintainability and, over the long-term, productivity. You can read about this in depth in "Cem Kaner's Article 'Improving Maintainability of Test Suites'":http://www.kaner.com/lawst1.htm To summarise my experience, the benefits in simpler terms are: # **Reduces code-changes, hence Reduces Risk** You don't need to rebuild your code if you want to add/change tests. This doesn't mean that you can't change your version number if you change your tests, however. In my experience, rebuilding your code always carries a small risk. # **Reduces maintenance effort of test-code** If your test-implementation has to change during refactoring but the test-objective remains the same for many of your features or classes, you have a lot less code to change because the intput-data and assertion-data are decoupled from your code... also reducing risk # **Reduces maintenance effort of test-conditions** Because your input-data and assertion-data are in your data file and, usually, will require less syntax to add or edit test-conditions, there is less effort involved in maintaining your tests. If you use a format that is easy to update by non-developers, it also allows non-developers/non-automators to easily review your tests and add new test conditions - ones that perhaps you hadn't thought of. # **More effective test-design** Separates your thinking about 'implementation of the test-execution' from your thinking on 'what you are trying to achieve with the test'. Designing your tests in terms of input and assertion data keeps you focussed on the techniques you can use to determine the most effective tests. Because your thinking is focussed in a narrow context, you are doing less multi-tasking - hence able to be more efficient and effective in designing your tests. The data-source then becomes the outline design of your test. There are many more context-specific benefits that you will discover as you implement this approach... More advanced implementations of data-driven testing are **key-word driven** approaches. This requires a more advanced generic test framework where, as the input is parsed, it is used to determine both the action and the related input/assertion. This is used to some degree in the "Action Fixture of the FitNesse framework":http://www.fitnesse.org/FitNesse.ActionFixture (based on "FIT":http://fit.c2.com/ ) but can also be much more powerful, as in some GUI-Test-Tool key-word driven frameworks. You can read more about this in "Carl Nagle's Article 'Test Automation Frameworks'":http://safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks.htm. Although FitNesse can, in theory, be used as a unit testing tool, it may not be the most effective way of doing it. I am aware of two extensions to the **JUnit** Framework that allow you to implement data-driven tests: * "JTestCase":http://jtestcase.sourceforge.net/ * "JUnitPP":http://junitpp.sourceforge.net/ "MbUnit":http://blog.dotnetwiki.org/category/14.aspx?Show=All also supports data-driven unit testing in **.NET** * "Data Driven Testing with MbUnit":http://blog.dotnetwiki.org/archive/2004/05/13/208.aspx I have also worked on a project where we implemented a simple XML driven framework using "NUnit":NUnit - and I am sure we aren't the only ones who have. So, perhaps you are sold... perhaps you aren't... All I will say is give it a try...