
My Version of “TDD Is Design, Not About Testing” - waterlink
https://www.codementor.io/daveschinkel13/my-version-of-tdd-is-design-not-about-testing-bkjc9gjp1
======
eesmith
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...](https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System)
:

> 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?

------
dozzie
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.

