It helped, but it didn't replaced tests.

Why? Because the code has to be run in order to check these precoditions, postconditions, class invariants etc.

And if a method isn't called during testing, all your assertions are vain.

I ended up rerunning the application all over just to make sure these assertions were executed and checked. But the test suite should have done that, not me manually.

There's nothing wrong with DBC (and I like the fact that Perl 6 will come with it by default), but it's just not enough.

And if the code (or "method" -- I need to get my OOOrthodoxy checked) isn't called when you use the program, it probably doesn't matter. If you're writing code you don't use, you've got a more serious problem.

If code isn't called when you routinely use the program, you won't initially find the bug. When the rare case or corner case occurs, though, it'll be a pain in the rear to track that bug down.

Let's just hope you never have to write a script that does X on weekdays or Y on the weekend, but Z if the date is February 29th ;-)

"Test first development" seems to me to be a blunt tool for people who don't understand their code, or even make a serious effort to do so.

Thank you, downvoters, for making my point.

Martyr much? I didn't downvote you, but I do object to your implication that I don't understand my code or make a serious effort to do so.

Feel free not to use any of my code, if you think I'm such an amateur.

I was speaking more about the design side, using it more, to borrow your words, as a blunt tool to design the project. My idea (which as I guessed is not even close to a new concept) was just to combine the time spent spec'ing out the project with the time that would be spent later on writing tests.

What do you do as your first step in the design?

I think about the problem and solution, trying to come up with its governing laws. Sometimes I write math and pseudocode in a notebook.

Sounds like how I approach a physics problem (physics is a domain where I've much more knowledge than programming): just think about the problem and constraints, and then "just do it."

I think that you are right, that tests as a design tool are somewhat of a crutch for the inexperienced. But, as far as crutches go, they seem to be a pretty good one. The automated tests you create during design follow through and help you during development, and it gets you thinking about the module user's experience.