When you're doing test driven development or, in fact, any kind of testing, there's a tendency to test only the success paths of the program to make sure the system does what it's supposed to do. It's just as important, however, to test the failure paths as well. You have to test that the program doesn't do what it's not supposed to do. If your program expects a start date and end date, what happens if the end date is before the start date? What happens if they're equal? If the user is editing an object in a window, what happens if another user deletes that object before the first one saves? If you expect a number from 1 to 10, what happens when an 11 comes in?
In my experience, if any bug could possibly occur, it will. It's better for you to find it in the lab than to have the end users find it in the field.
Download