Eric Smith joined 8th Light to do higher quality work. TDD has won, the debate is over.

Uncle Bob has gone on record pacing back and forth saying “You are unprofessional if you haven’t written a single line using TDD”

Unix largely doesn’t use TDD to be developed. In order to be a professional, you work on an unprofessional operating system, developed on a platform that wasn’t used TDD

TDD has 3 claims it makes, today’s talk is the case against TDD.

• Code with tests has minimal bugs
• TDD makes us faster, faster feedback (working on good code, and clean code)
• TDD leads to better design (promotes the minimal amount to do)

TDD Reduces Defects

If you look at a subset of the tests for something that does something you have a lot more test lines of code than actual code
Assume writing tests reduced your bug defect by 75% You are still introducing bugs, just potentially in tests code The mess is in your tests

TDD Makes us faster

Your most complicated code is in your unit tests, the tests get more complicated than the actual code
The more abstract you make test codes, the harder it is to understand
That’s why we copy/paste tests when we write new tests

We spend an enourmous amount of time debugging the build system
Tests become a maintenance problem
Unit tests add easily twice as much code
TDD doesn’t really make you run faster, because you have moved the time to maintaining the tests

TDD makes better design

Better design = more testable
This is a circle loop
DHH spoke about TDD pain
Bob Martin says the second guy pays for the abstraction Writing tests often forces the abstraction (the tests become the second guy)

So was this all a waste?

One of the things that happened with TDD was that it came out of the dynamic paradigm, you don’t have any types so you need something… tdd Static types are free tests, we threw them away because we didn’t want to type them
You can’t forget to write the type checked… you can forget to write the tests What if all maintenance pain was gone?

Design by contract is older than TDD and a lot of the design principles were used in TDD The basic jist of DoC is that every method has pre conditions and post conditions
QuickCheck or property based testing are great options
There is still a need for unit tests, in certain places

There is a scientific test that said writing tests leads to being more productive… what does this tell us? It tells us that we are crap at evaluating our field

TDD != Craftmanship

• Testable != Good
• Prove your Assertions
• Don’t be jerks
• Remember that everything is a tradeoff, even good ones

TDD is actually a Fad
Fad doesn’t mean it is bad
Sometimes fads get overdone