Blogs

Hi again everyone,

I’m a big fan of test-driven development, so I figured, what better way to evangelize than to blog about it? I’m mostly going to talk about TDD within the context of some recent work I’ve been doing at Nitobi. The project I’m working on is all .NET-based, so our main development tools are:

• Visual Studio (duh!) together with MS SQL Server,
• NUnit, an open-source unit testing framework for .NET projects, and
• Selenium RC + ASP.NET driver, a functional testing server and framework for web sites

For the ASP.NET web application I’ve been working on, we decided to implement and maintain two sets of tests: unit tests to make sure our back-end code was sound, and functional tests written for and executed using Selenium, to make sure our application behaved properly from a front-end perspective. However, soon after we started writing tests and feeling good about ourselves, we realized that writing individual test cases is practically impossible from a maintainability perspective, especially the front-end, or Selenium, tests. The reason is that most serious web applications are composed of a lot of “layers”: many levels of navigation, internationalization, even different views/features provided to end-users based on the browser the user is using. Writing a test case for each combination of these variables quickly adds up.

So what were our options? Given that we were using NUnit as the core testing framework, we looked at what add-ins NUnit had to offer. First, there’s the RowTest add-in, which allows you to create data-driven tests. Cool, I thought, exactly what I needed. That was quickly abandoned, though, because you manually had to specify what the data being passed into the test is! Not very useful. Next there was the IterativeTest add-in. Very simple and powerful idea: your test takes as an argument a function that returns an enumerable (something that implements IEnumerable). You can then use this argument in your test, and forget about writing the same test n times. Yay! Perfect, right? Yes… but it wasn’t good enough for us . The reason is because the current IterativeTest add-in that is up on the NUnit home page can only accept one enumerable argument (plus only works with NUnit 2.4.5 :s). So what happened was that Arthur C., good friend and ex-co-worker of mine on this project, extended the add-in and made it work with as many arguments as you like, and not just enumerables, too! It works with pretty much any type (including class getters). The add-in then creates combinations of each IterativeTest argument value and creates a separate test case for it. This ended up saving us a lot of time, and came in handy for two big functional, Selenium-based testing scenarios:

1. A web application that is localized. Internationalization is a big topic these days, and being able to run tests for each set of supported languages is pretty sweet. To use my project as an example, we stored the languages in the database, so our test suite implemented a function that dips into the database, grabs all of the languages and returns them as an ASP.NET ArrayList object. This was then passed into pretty much all of our test cases, so that they were run for each language.
2. Testing across browsers. Selenium gives us the ability to run the tests in various browser instances, so it’s quite easy to create an ArrayList of browser executable names (’iexplore’, ‘firefox’, etc.) and pass these into your test cases. The test case then creates an instance of the Selenium server, speciying which browser to use as the agent, and executes the test.

So, everyone, please feel free to grab the IterativeTest NUnit add-in that we’ve put together. It works for NUnit 2.4.8, too. The binaries are linked above. For the source, check out my repository that’s up on GitHub. As always if you have stuff to add or comment on, just fork away and keep in touch!