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:
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.
Powered by: newtelligence dasBlog 2.3.9074.18820
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.
© Copyright 2012, © Copyright 2010
E-mail