# Thursday, October 21, 2004
« Error Handling | Main | Grabbing a random record using T-SQL/SQL... »

With the advent of test driven and test first development, writing meaningful tests can be a bear. There are a lot of methods, such as data shunting and hardcoding values, which avoid using the database for testing. While this can test the code, it doesn't test the database CRUD. I believe I once read that 80% of all applications are database applications, so testing the database portion is critical.

Personally, if you write tests which avoid directly testing your data schema and access methods, you're asking for trouble unless your Business Object tier is very robust. Even then, schema changes might be missed in testing if they don't actually interact with the database.

I am currently using nUnit for running the automated tests, and so far I absolutely love it. However, writing meaningful tests can sometimes take longer than writing the actual code, and as enhancements occur maintaining your tests can bog down the progress of the application. Changes inevitable, expecially in XP programming with their short development iterations.

Automated testing also invites buggy code if the developer is not careful. Here's some examples:

  • Some developers feel this takes place of unit and integration testing. This absolutely isn't true, as automated testing typically only checks individual functional testing (unless you have a very comprensive set of test cases developed -- suddenly these tests don't seem so agile).
  • Automated testing for the UI is limited at best. While nUnitAsp exists, it's not quite up to par to replace real-life beating-the-hell-out-of-the-UI testing.
  • There's absolutely no way to predict all of the ways a user if going to use your application unless you are a UI and Process Flow God/Goddess. Most programmers aren't, so you aren't going to be able to foresee all possible combinations of testing.

Bottom line is this. Use automated testing to test functionality against expected results, but this is only about 25% of the actual testing you need to do, regardless of whether the application is internal or external.

How a tip turned into a rant, I don't know.. So I guess I am putting this under Design, and making a second tip out of it.