My Version of “TDD Is Design, Not About Testing”

I think anyone who argues that TDD "Was Proven to Work in 1996" because of the C3 project must also explain how TDD was proved to work better than non-TDD methods.

After all, we can point to many successful non-TDD projects.

Otherwise the argument is the more limited "TDD doesn't cause projects to fail."

"both sides (Test First Design devs vs. Test After Devs)"

There isn't a simple "Both sides". There's TDD and non-TDD, but non-TDD encompasses a range of practices.

"Unlike test after, we rarely debug;"

Yeah, umm, no. I did a security analysis ones of a well-known testing project developed using TDD and found enough security holes in the web interface that I could execute my own code on the server.

Most of those security holes were due to implementation bugs. One in filename validation during upload. The Java code checked that the file ended with the correct extension. I passed in a string containing the \0 character. The Java code validated that the extension was correct, but the OS truncated at the \0 so I got to specify my own extension before it.

Another problem was that the filename for the download service could start "../../..", which gave me access to the server's own password file. Furthermore, the passwords used a simple hash function of the developers' own design, which took a couple of hours to break.

Yes, these are well known security holes in web servers. No, the developers didn't know about them.

Or, go back to the C3 project. Wikipedia helpful comments at https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... :

> Performance was something of a problem; during development it looked like it would take 1000 hours to run the payroll, but profiling activities reduced this to around 40 hours; another month's effort reduced this to 18 hours and by the time the system was launched the figure was 12 hours.

Tell me again how TDD helps with these sorts of bugs? Or are security and performance considerations something other than debugging?

If TDD is design, it's a stupid strategy. The only thing you'll get out of it is code that can be easily tested, not the one that is easy to use or robust. If you want good and robust code, aim for good and robust code, not for some vaguely-related proxy. Automated tests, when they were invented, were about not introducing regressions, not about influencing a design.