

Is TDD Dead? - merrua
http://martinfowler.com/articles/is-tdd-dead/
A series of conversations between Kent Beck, David Heinemeier Hansson, and Martin Fowler on the topic of Test-Driven Development (TDD) and its impact upon software design.
======
tpatke
My experience with TDD is that it is very helpful from a design perspective
because it gets you to think about the code before you write it. How is the
API going to work? What should I name this method? As an industry we use to
dedicate too much time to this (RUP, etc). Now, we don't think about it
enough.

As far as actually improving code quality... not so much. For the money, I
would much rather see an hour of functional test development rather than an
hour of unit test development (and I put TDD in the unit test category). I
think functional tests provide more value and our industry has put way too
much emphasis on unit tests.

100% unit test coverage says nothing about code quality. 100% functional
coverage does. Functional tests also tend to be less brittle – which is a nice
bonus.

~~~
rdtsc
Haven't seen the supposed benefit here as well.

I tried it as an experiment. With 100% coverage, TDD everything.

Code still fails in production. That is because unit tests detract from
running functional/integration tests. Database, connections, hardware all
mocked and each little cog is the right size. Put the cogs together into a
gearbox and it shits the bed.

The one thing TDD helped was to find exact code breakage easier. Functional
tests give higher level (less precise) error, maybe "something failed in the
backend" then one has to look at logs to see what happens and such. But I'll
take that over a false sense of security.

So am definitely not against unit tests, I am all for having a mix of both.

Another way to look at it, unit tests are a bit like drugs. It is easy to get
addicted, create 10000 tests and a little micro-burst of pleasure hormone
every time you see the dot on the screen for a passing test, it just feels
good. But it is important to realize that is what it is (maybe I am writing
all those tests just as a therapeutic exercise...), as it might not translate
immediately to a ship-able working product.

~~~
tieTYT
I test your way, but if you're not aware of it you might want to watch this
talk called Integration Tests are a Scam:
[http://www.infoq.com/presentations/integration-tests-
scam](http://www.infoq.com/presentations/integration-tests-scam) It may
explain why the "gearbox shit the bed" and how to fix that problem.

If you want a talk that preaches to the/our choir, check out this one:
[http://vimeo.com/68375232](http://vimeo.com/68375232)

It's interesting how different they are. Mutually exclusive in fact. But is
_one_ wrong, _both_ or _neither_?

~~~
rdtsc
> Integration Tests are a Scam:
> [http://www.infoq.com/presentations/integration-tests-
> scam](http://www.infoq.com/presentations/integration-tests-scam)

Thank you, that was interesting! A lot of good points. I agree with some of
them and don't agree with other parts of it.

First, let's start with this basic principle -- "customers don't care if I
have 1M unit tests or 0 unit tests". They just don't. They will complain and
not like my product if it keeps crashing or is showing other pathological
behavior. First and foremost it is important to ship, and to ship working code
as far as customers are concerned. Taken from that side, I want to ensure that
when the system is setup in customer's configuration (and we do know it, in
our line of work), then we want to stimulate the system as close as possible
to what a customer would do. If that doesn't break and is behavior properly.
We gain immediately a large degree of confidence because it is closer to
"doesn't break when customer uses" use case.

Unit tests also promise that, and they would also promise that "if I have
unit-tested my code well, there is a higher chance that the code will not
break when it gets into customers' hands". However notice that this is further
from being true than the first one.

The problem with integration tests as discussed in the talk it they take a
long time to run and give imprecise results. When something is broken I might
not be able to quickly zoom in on it. I can't experiment as often as I would
like because it take too long to discover precise mistakes. And I agree with
those, but, I still maintain it is better to have integration tests because
once you get into a stable steady state and all of the sudden one commit
breaks the tests it usually is pretty clear what broke, in the worst case just
revert the commit or examine in detail until it works. That helps with the "I
don't know what broke, something did" part. Usually that something is the one
commit where tests started failing.

Yeah, it would be better to also have complete 100% unit test coverage as well
and zoom in immediately on the problem. No doubt that 100% unit test coverage
also costs a lot of time and money and I posit it is often un-necessary.

Another criticism, perhaps I misunderstood the presenter, it seems to me that
the talk focuses more on machine-local, object oriented code. Today the
systems are more and more distributed. In a pure, local, single threaded,
object oriented code (say a 3D modeler or Photoshop).The behavior or objects
is more predictable and it is easier to write what he calls "focused tests".
Now introduce threads and well that starts to become hairy. Add in multiple
machines (a distributed system) and it gets even more complicated. There is a
whole slew of strange problems. Often involving consistency, timeouts,
networks failure, partitions, hardware peculiarities. Un-expected input that
is generated maybe because a front end service is broken and back-end write
might never expect that case and crashes. Unit tests will catch basic errors
but it will mask those harder to find those kind of errors.

One more criticism is psychological and it is the false sense of security. And
I have seen this happen from those that advocate unit testing everything 100%,
when their code breaks, they simply don't believe their code could break
because it has 100% coverage and they "just ran it and it passed". Well in
production it crashes. And customers don't pay for passing tests they pay for
a working product. Anyway I am repeating myself at this point and this is
longer rant, so, sorry about that.

~~~
tieTYT
> The problem with integration tests as discussed in the talk it they take a
> long time to run and give imprecise results.

I think you left out the main complaint: It's impossible to cover a majority
of code paths.

------
spion
Software architects arguing about methodologies without discussing the real
problems and context where those methodologies are applicable - because they
can't show that code. Instead they use some fuzzy general notions which don't
communicate any relevant information.

I don't understand - how is this useful? Can anything be learnt from this at
all? Its very clear to me that no useful conclusions can be reached from
debating like this - is it just me?

The only substantial content was a comment on the gist [1] that explores a
problem that looks like it came from a production system. Methodology
discussions would really benefit from at least one semi-realistic example like
that.

[1]:
[https://gist.github.com/dhh/4849a20d2ba89b34b201#comment-122...](https://gist.github.com/dhh/4849a20d2ba89b34b201#comment-1228640)

------
logfromblammo
Was TDD ever really alive? I have a hard time getting less technical bosses to
accept automated unit testing at all, without having them just reduce it to a
% coverage metric that I not only have to report, but also satisfy annual
goals. For them, TDD is a potential source of new buzzwords.

TDD is one of those things that only works when developers have a high degree
of control over their own work. Anecdotally, that has been hard for me to
find.

I think the only way to get widespread and useful adoption is to actually
construct a high-level language around it, such that the code and the test are
tied together by syntax, in the same file, and coverage is enforced by the
compiler.

Otherwise, you're stuck trying to enforce TDD via voluntary human cooperation.
While you may have confidence in writing and refactoring your code, that just
shifts the uncertainty that remains in development of a complete product onto
the screening of new hires and avoidance of certain management edicts.

Essentially, you need a fully automated test cop.

~~~
njharman
For the environment you describe in first sentence, no good software
methodology could live. It's just not possible (unless you ignore them / break
"rules") to create good software with incompetent, meddling, pointy heads like
that.

~~~
logfromblammo
That sort of environment is depressingly common outside of the major tech
hubs. My current employer just _celebrated_ its millionth line of code on a
glorified CRUD+reports application. I have been _reprimanded_ for _suggesting_
better development practices. Obviously, I am trying to find a better job that
still pays reasonably well for a 40-hour work week.

~~~
taurath
Damn - has anyone suggested to them to perhaps pick a non-LOC based milestone
to celebrate at? Or perhaps was the announcement aimed more at non-technical
folks elsewhere in the company?

------
manishsharan
I used to be TDD fanatic with java junit + spring unit tests and I went for
100% test coverage .

However, in my Clojure code, I feel 100% test coverage is unnecessary. REPL
does a good job of proving my code works as intended. I wonder if I am doing
it wrong!

~~~
wpietri
A REPL does a good job of proving your code works as intended _now_. If you
save that code in a file and run it regularly (which is a fine way to start
making a test suite), then you can prove your code still works _later_.

That's especially important when multiple people work on a project: you have
some chance of remembering what important REPL incantations prove a system
works. They won't. If you haven't put your REPL magic in a test suite, then
they're going to break your stuff.

------
josephlord
In part IV DHH says that he believes the code should be the master reference
over the documentation or the tests. The problem with that is there can never
be a bug because current behaviour is by definition the reference behaviour.

------
dang
Burying as dupe.

[https://hn.algolia.com/?q=is+tdd+dead#!/story/sort_by_date/0...](https://hn.algolia.com/?q=is+tdd+dead#!/story/sort_by_date/0/is%20tdd%20dead)

------
lvh
I can't find the summary. This appears to be a link to the videos themselves.

~~~
heroprotagonist
You need to click the 'more...' button at the bottom of each topic to see the
summary.

~~~
mistermann
Wow, thanks for that....what a terrible UI presentation.

------
gress
Specifying invariants via tests before or during the writing of code is a
great technique.

Making your whole development approach blindly revolve around one technique is
self-evidently a poor idea.

------
mantraxD
Well. It's... it's good he calls it "Summary", because if he called it "Brief"
it'd be very ironic, correct?

Like any experienced developer I have a lot of respect for Martin Fowler and
his work, but sometimes I wonder if his best skill is saying simple things in
many, many, _many_ words.

~~~
Sarien
Well, could anybody sum this up? Because I'm definitely not going to read Part
2 since it seems Fowler didn't even bother to produce correct sentences.

~~~
erikpukinskis
Automated tests are awesome but they aren't useful in all cases and it doesn't
always make sense to write them first.

------
mavdi
_INSERT STUPID ATTENTION GRABBING HEADLINE_

------
romanovcode
No.[0]

[0]
[http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines](http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines)

~~~
phpnode
[https://news.ycombinator.com/item?id=4722251](https://news.ycombinator.com/item?id=4722251)

~~~
tempodox
I disagree. Betteridge's law is useful.

~~~
Sarien
It is a shitty generalization slandering all articles which (possibly poorly)
chose a question as headline.

This is obviously an "article" where the author was legitimately interested in
answering the question in the title. This is one of the cases where
Betteridge's law does not apply.

Betteridge's law may be useful to remind people to watch out for poor
journalism and fact checking. In that case, I propose that all articles shall
henceforth use questions as titles because people should do that anyway.

~~~
romanovcode
It's funny because author at the conclusions basically says that it is useful
and people should use it hence the answer to question "Is TDD Dead?" is No.

