Roy Osherove is a cool guy! No doubt. Reading his blog post below though made me think that what he is describing is more system integration testing or customer testing than actual Unit Testing. As he mentioned his application consists of many layers and therefore changing your database schema should not inflict your business layer!

So for your unit tests to act autonomously you need to ensure that your e.g. business layer unit test are independent from your data access layer.

So you want to test that calling ‘deleteCustomer’ calls the data access layer with correct parameters (not caring if the data access layer are screwing it up). You would then have to stub out your db layer with either static or dynamic mocks.

I suspect this is what Roy also did since only five tests failed, however its not that clear from the article. Point is you could change your database completely (e.g. to DB2) and assuming your business logic stays the same only the tests that access the database directly will fail. Just my 2 cents.

How Test Driven Development proved itself in a big way!

Over the past year or so I've been going around trying to tell people how and why test-driven development will help their development process. Its hard to convince people. It's actually still hard sometimes, even after people have had real-hands on experience (after attending one of my TDD workshops). Why? because its just too good to be true , sometimes. And being afraid of what to tell your boss matters too.

 

So here's a good story you can tell around the camp fire. Today I've experienced one of the most gratifying results of writing unit tests. We have a system that is near production ready, which involves lots of layers, logic and data. Today we had to do one of the most scary things you can do to a system that is near production - change the indexes of most of your database tables, including some primary keys, then go through all the stored procedures and change them to fit this new schema. How scared would you be?

 

Heres how it worked for us:

• Downloaded CodeSmith (awesome application, that.)
• Created a simple template for stored procedures against all db tables
• Ran the script against the database - generating only DELETE procedures
• Ran all the tests
• 5 tests out of about 200 failed
• We tweaked the procs a little by looking at the old database
• Ran all the tests
• All the tests were green
• We continued the same process for Update and Select procedures.
• It took 4 hours to complete this whole experience, with all the tests running in the end.

Imagine doing this on your system today. Would you even consider it?

This is agility in its truest form: The ability to make changes to the system when you need it. And knowing what breaks when you actually do it. And being able to fix it and know that you actually did fix it.

I could easily say that the Unit Tests paid for themselves just from today's experience. not to mention the amount of time they have already saved thus far. I am now throughly convinced that Test-Driven development is one of the best ways to tackle, if not reduce, the amount of risk in today's average IT project.

 

If you're all now thinking "we don't have time to incorporate the complete "Extreme Programming" process into our Dev team - you don't have too. the project I'm talking about is NOT doing full on XP. however, TDD is a big part of it, as well as customer on site and refactoring. Some pair programming was done in several parts of the project, but not all of it.

 

I can certainly say that had we not had unit tests - we would be doing today "Prayer Programming" :)