3 ms·

> TDD won't help you solve problems that you don't already know how to solve: I talk a lot about web application security. The following line from flesh and bl

> TDD won't help you solve problems that you don't already know how to solve: I talk a lot about web application security. The following line from flesh and blood developers on multiple occasions: "Shouldn't your tests catch security vulnerabilities?" To which I always respond: "Yeah sure, they'll catch the vulnerabilities that you already thought of" I've personally seen codebases with test suites that cost (even with the most conservative estimates of time spent and day rate) upwards of 300,000 USD with 100% coverage that allowed an anonymous client to drop the users table. If a lack of security bugs (and therefore bugs in general) is any indicator of software quality, TDD has yet to impress me in the wild. My development process has always been to prototype out three or four implementations, evaluate them against the known use cases and then settle on a final API design. Then I'm ready to do TDD. Glad to know I'm not the only one who works roughly this way. It also bugs me a little that many otherwise intelligent developers use TDD as their sole software design tool much of the time. The exact term they use for this is using tests to "drive out" a design. While I understand this may work in textbook examples, in real life I've seen the concept being used to justify designs that clearly aren't fit for purpose.

InclinedPlane 13y ago
That illustrates a very serious problem with TDD, the idea of coverage. 100% code coverage is not 100% coverage of every different possible code path. In fact, for most software systems it is not even remotely feasible to achieve that level of code path coverage. The "100%" figure can easily lull less experienced devs into thinking they have sufficient test coverage when nothing could be further from the truth.
- mbrock 13y ago
  However, TDD encourages – ideally – a style of programming where 100% branch coverage is likely to mean the program is correct. That's part of the idea of the "unit" in "unit test." You decompose the program into units for which correctness is relatively simple – and testable. How to do this properly is not obvious, and for teams on which TDD is imposed without this understanding, it will all become a bizarre and useless ideology. When it is understood, the resulting program will have properties that resemble those of purely functional programs, especially composability and correctness.
  - seanmcdirmid 13y ago
    > when it is understood, the resulting program will have properties that purely functional programs, especially composability and correctness. It is not that hard to write pure functional code that is not very compassable or correct. Keeping it simple stupid is more important.
amorphid 13y ago
This isn't a problem with TDD. It's a problem with the developers using it. TDD doesn't protect you from being a moron.

InclinedPlane 13y ago

That illustrates a very serious problem with TDD, the idea of coverage. 100% code coverage is not 100% coverage of every different possible code path. In fact, for most software systems it is not even remotely feasible to achieve that level of code path coverage. The "100%" figure can easily lull less experienced devs into thinking they have sufficient test coverage when nothing could be further from the truth.

mbrock 13y ago
However, TDD encourages – ideally – a style of programming where 100% branch coverage is likely to mean the program is correct. That's part of the idea of the "unit" in "unit test." You decompose the program into units for which correctness is relatively simple – and testable. How to do this properly is not obvious, and for teams on which TDD is imposed without this understanding, it will all become a bizarre and useless ideology. When it is understood, the resulting program will have properties that resemble those of purely functional programs, especially composability and correctness.
- seanmcdirmid 13y ago
  > when it is understood, the resulting program will have properties that purely functional programs, especially composability and correctness. It is not that hard to write pure functional code that is not very compassable or correct. Keeping it simple stupid is more important.

amorphid 13y ago

This isn't a problem with TDD. It's a problem with the developers using it. TDD doesn't protect you from being a moron.