
RIP TDD - platz
https://www.facebook.com/notes/kent-beck/rip-tdd/750840194948847
======
revscat
This... is not Kent's finest moment. I get what he's saying, but the snark
doesn't really help, and doesn't actually rebut any of the points that DHH was
making against TDD.

Testing _does_ tend to have a negative impact on API design. If we were to
make a list of positives and negatives, this one would go in the "negative"
column. Listing out TDD's positives does not invalidate that negative.

~~~
kasey_junk
"Testing does tend to have a negative impact on API design"

I think this sentiment is the single root cause of the current back in forth.
In my experience this is completely untrue. For DHH and others there appears
to be some sort of culture of dogmatic polluting of APIs for testing which I'm
not familiar with.

Everything else seems to be talking around the real issue and finger pointing.

~~~
revscat
Let's take as an example dependency injection. The genesis for DI was to
facilitate the testing of objects that are dependent on objects that are not
easily constructed, such as DAOs. And the whole reason this was done was so
that these classes, the ones that have a DAO dependency, could be more easily
and quickly tested.

So, in order to use (constructor) DI you would have a constructor that looks
like this:

    
    
        public InvoiceController(InvoiceDao invoiceDao) {
            this.invoiceDao = invoiceDao;
        }
    

The key point to remember here is that this has been done so that in our unit
tests we can inject a fake InvoiceDao. Now, let's say that our InvoiceDao
class has one and only one constructor:

    
    
        public InvoiceDao() {
            // sets up connection parameters, etc.
        }
    

Then the constructor for InvoiceController could be simplified to:

    
    
        public InvoiceController() {
            this.invoiceDao = new InvoiceDao();
        }
    

This is quite a bit cleaner from an API perspective, _and that is the entire
point._ This is only a simple example. For more complex classes, with multiple
dependencies, it really becomes cumbersome. What if InvoiceController also
needed access ReporterDao? Well, then you need to add that as a parameter to
the constructor as well. Your API is made more complicated, all in an effort
to make testing possible.

This does not, of course, invalidate the benefits of unit testing, which are
many. But it does expose a negative that is not frequently acknowledged, and
that's what DHH is talking about, and what Kent has failed to address.

~~~
kasey_junk
"The genesis for DI was to facilitate the testing of objects that are
dependent on objects that are not easily constructed, such as DAOs. And the
whole reason this was done was so that these classes, the ones that have a DAO
dependency, could be more easily and quickly tested."

I disagree with this central premise. If you have introduced DI simply for
testing reasons than you have missed the point. The reason for DI is that a
very common point of change with software is at the interaction between
clients and services. Tight coupling at this point of change is usually a
design smell. That DI enables automated testing is a by product of it being
loosely coupled not the point of the loose coupling. That TDD drives you to
this sort of solution, all other things being equal, is one of the advantages
of TDD.

If DI has become cumbersome and is making your code hard to reason
about/read/maintain etc then blame DI, not the testing. You also might want to
consider the higher level architecture of your solution if you are finding
yourself with lots of complicated dependency chains.

~~~
jshen
"The reason for DI is that a very common point of change with software is at
the interaction between clients and services. Tight coupling at this point of
change is usually a design smell."

The problem with TDD is that if it is NOT a common point of change, TDD
adherents often say that you should introduce DI anyway to make testing
easier. "One day you might want to change out the whole database, so you
should abstract out the DB into a blah blah blah pattern, with a layer of the
rah rah rah pattern between to ..."

~~~
dragonwriter
> The problem with TDD is that if it is NOT a common point of change, TDD
> adherents often say that you should introduce DI anyway to make testing
> easier.

To the extent that's a problem, its not with TDD, nor with DI, but with the
particular people giving the advice. Why do people think that "Some of the
people who follow X give bad advice Y" is a criticism of X when Y is not
something that that X requires?

~~~
jshen
[http://en.m.wikipedia.org/wiki/No_true_Scotsman](http://en.m.wikipedia.org/wiki/No_true_Scotsman)

~~~
kasey_junk
This is a very insidious comment. You have actually committed the logical
fallacy as your position is "All TDD proponents do X". When someone points
out, no "Some TDD proponents do X and many of us TDD proponents think X is bad
practice" you blame them of the No true Scotsman fallacy, when in reality your
position is the one claiming a universal property about TDD.

~~~
jshen
Tell me who is a good representative of TDD that has written a lot about it.
Where is the cannon of TDD so to speak.

~~~
kasey_junk
Not sure if I'm qualified to appoint a cannon but I can tell you of the books
that were very influential to me with regards to TDD:

Test-Driven Development by Example, Kent Beck. This came out in 2002 and I
haven't read it since then but at the time it really influenced a lot of my
TDD thinking. I expect if I read it now I'd have some complaints based on my
decade of experience with the process.

Growing Object-Oriented Software, Guided by Tests, Freeman & Pryce. Much more
recent and includes more modern thinking about TDD with acceptance/integration
tests.

Working Effectively with Legacy Code, Michael Feathers. A great book for
dealing with TDD when you aren't doing green field development. He is a bigger
fan of Mock Objects than I am, but he illustrates some examples when mocking
is the most appropriate response to the current requirements.

All that said, TDD is like any other software methodology. It is a set of
patterns and principles that each practitioner interprets for themselves. At
it's core though it's pretty simple, automatic verification of specifications
are as important as implementation of the specification for any sufficiently
long lived, complex software system. Writing those verifications first
provides, design, process, and management advantages over the historical
process of writing them last and has a high correlation with well factored
code. That's it, no doctrines about unit vs integration tests, mocking out DB
access or 100% code coverage.

~~~
jshen
"and management advantages over the historical process of writing them last
and has a high correlation with well factored code."

Where is the data supporting this claim? I don't believe it is true.

"That's it, no doctrines about unit vs integration tests, mocking out DB
access or 100% code coverage"

Why do you think so many of us feel that it is an ideology? Are we seeing
ghosts and imagining the whole thing?

~~~
kasey_junk
"Where is the data supporting this claim? I don't believe it is true."

This is one central premise of TDD and is not proven or disproven yet. What we
can say is that previous software methodologies were lacking, and cannot prove
or disprove their superiority over TDD with regards to this statement. If you
distill all debates about TDD down to their essence, it revolves around this
premise.

I am fine with someone being skeptical of this claim, but I would prefer if
they offered A) a measure we can use to test this hypothesis and B) a
contrasting methodology that performs better with regards to the measurements
provided in A. The single biggest outstanding problem in software engineering
is finding a metric by which we can judge software quality objectively.
Because it is such an elusive goal other less precise proxies for software
quality have been proposed to stand in for the more complex metric. TDD hangs
it's shingle on "testability". Even though this has obvious defects, I've seen
no evidence for any other objective measure as a more precise indicator of
software quality and quite a few advantages to "testability". Namely, it is
measurable.

"Why do you think so many of us feel that it is an ideology? Are we seeing
ghosts and imagining the whole thing?"

No, I'm sure that you have encountered well meaning but flawed practitioners
of TDD. Your skepticism of their process doesn't bother me. What bothers me is
your (and DHH's) painting of all TDD folks as cultists. I don't believe this
stuff because Uncle Bob told me to believe it. I believe it because my
experience shows that rigorous use of TDD practices trend toward better
software than a lack of rigor outside of an objective measure for software
quality.

If you have an alternate rigorous approach that you believe trends (or better
yet is provably) better in software quality, by all means outline it. I know
that TDD is flawed and am happy to find its successor.

Let me ask you this, prior to the rise of TDD, how prevalent do you think
automated testing was? If it was very prevalent why is it only after the rise
of TDD that automated testing became a central part of any build workflow and
the entire concept of Continuous Integration/Deployment developed?

In my experience, automated testing prior to the rise of TDD was not wide
spread. But maybe I was seeing ghosts and imagining that.

~~~
jshen
Neither of us ever said all TDD folks are cultist. We are both tired of being
told that we are absolutely doing it wrong if we don't practice TDD. For an
example of people telling us this please see this talk by bob Martin and jump
to the 58 minute mark.
[http://m.youtube.com/watch?v=WpkDN78P884](http://m.youtube.com/watch?v=WpkDN78P884)

Bob is not an obscure figure by any stretch of the imagination. You have
admitted to having no real data to back up the claim that writing tests first
leads to better code, yet we have bob here telling us we are absolutely wrong
if we don't follow his religion.

------
vinkelhake
Is this a joke or he is he just unable to separate "tests" from "test driven
development"? Most of these points have nothing to do with "tests first".

~~~
anon1385
>Is this a joke or he is he just unable to separate "tests" from "test driven
development"?

I'm not sure I've ever seen a debate about TDD without at least one TDD
advocate conflating testing in general with TDD…

------
jshen
He ignores the points DHH makes, and then replies with his own snide talking
points like a politician on a sunday morning talk show.

~~~
mbillie1
DHH largely creates a straw man: the fanatical, religious TDD devotee who
blindly worships at the Altar of Unit Tests. For an enormous majority of the
wider development community (who do no testing whatsoever outside of click-
the-thing-and-see-if-it-works), TDD is an easy to understand, easy to get
started way to improve the quality of your code. I haven't met any of these
supposed religious zealots DHH is railing about, and I worked for an "Agile
Consultancy".

Also, DHH argues against plenty of other best practices / design patterns and
is considered incorrect in many of these cases (his "only use the Rails
classes" objections to having a service layer most famously). It just so
happens that when he bashes something that a lot of developers don't _like_ to
do already (write unit tests), the pitchforks rally behind him.

It's the same sort of thing when people post articles on HN bashing pair
programming, or open workspaces. We get it. Some of you really don't like
change, or anything "agile". Now please stop beating the dead horse already.

~~~
spamizbad
> DHH largely creates a straw man: the fanatical, religious TDD devotee who
> blindly worships at the Altar of Unit Tests.

That's not a straw man: That's real life. I've worked with people like this.
They're fairly common in TDD shops. You even see them on Hacker News making
spurious claims like how TDD would have prevented the <security hole> in
<framework> (nevermind the fact that that <framework>'s dev teams is heavily
invested in TDD)

~~~
mbillie1
I've worked for one of the biggest agile consultancies around, and while most
of the developers write unit tests, I never met anyone who started frothing at
the mouth if we wrote code before tests. I just don't buy the pervasiveness of
these TDD-devotees to the degree that justifies all of this backlash, DHH
articles, HN comments, etc.

~~~
raverbashing
You probably got lucky.

But yeah, they exist

------
Arkadir
Look at Kent's eight bullet points: half of them are unrelated to the DD part
of TDD. Coming from a man who should know the difference between having
automated tests for your software and partaking in test-driven design, I must
assume that he had a good reason for conflating the two.

Hacker News is not the audience for this post.

Kent Beck is doing damage control.

DHH lives in a developer community that has adopted unit tests to the point of
feeling ashamed about untested code---testing is more than just a practice,
it's a culture.

Kent Beck lives in a world where the mere existence of unit tests is a
champagne-worthy surprise.

There are people out there who are not yet convinced of the benefits of tests,
let alone test-first or test-driven design. Kent Beck is a missionary,
bringing them the gospel of automated testing. Can you imagine the impact that
a piece like DHH's would have on his efforts ?

A developer with an incomplete understanding of software tests, reading a post
by a big-shot recognizable name that one would expect (based on the Rails
community's love for testing) to be a major proponent of tests, would take it
as "Tests are actually a bad idea !"

This is not what DHH said. There is probably no one among us here who would
understand it this way, and most experienced folks would just shake their
heads at the ongoing back-and-forth and resume their position of "TDD is a
tool in my toolbox, and I use it whenever it helps me."

Kent Beck wrote a piece for the lost soul who doesn't know the difference
between TDD and automated testing, and who might become confused after reading
DHH's opinion. This is no time for subtlety, for paying notice to the
differences between testing methodologies, or for polite agreement with at
least some parts of the "opposing" piece.

Let David work to bring the Rails community back from the "test all the
things!" extremities it might have reached, let Kent work to bring the
unenlightened masses out of the "tests are useless!" darkness wherein they
have dwelt for so long, and let us accept that if we truly have the capacity
to criticize what those two are saying, then they probably weren't talking to
us in the first place.

------
projectileboy
Kent Beck is normally intelligent, concise and persuasive. This post is
reactionary, and disappointing. I hope he follows it up with something a
little more considered.

~~~
protomyth
He has books and lectures on the subject so I'm not sure he has much more to
say.

------
platz
Jessica Kerr was discussing property-based testing (i.e. quickcheck,
scalacheck) on a podcast recently, and I thought it was interesting she noted
that the red-green-refactor cycle didn't make as much sense with property-
based testing.

It's more "contemplative" \- thinking about invariants of your software rather
than designing for mocks and various injected components.

(although property-based testing is a bit less effective in languages that
don't make type information available, to generate the input values)

~~~
icebraining
Is this the podcast? [http://www.functionalgeekery.com/episode-8-jessica-
kerr/](http://www.functionalgeekery.com/episode-8-jessica-kerr/)

 _/ downloads_

~~~
platz
yep! Although it's kind of a weird dynamic going on - the host gets defensive
at times, getting a sense these two were grating on each other a little bit.
Always enjoy the things Jessica has to say though.

------
gregors
I'm guessing this doesn't disappear anytime soon
[https://github.com/rails/rails/tree/master/activerecord/test](https://github.com/rails/rails/tree/master/activerecord/test)

------
hissworks
An indirectly related fixation that bugs me every time I see a Facebook link
is this: why are notes, events, etc. appended with a string of digits?

Shouldn't the URL here be simply: [https://www.facebook.com/notes/kent-
beck/rip-tdd/](https://www.facebook.com/notes/kent-beck/rip-tdd/) rather than
[https://www.facebook.com/notes/kent-beck/rip-
tdd/75084019494...](https://www.facebook.com/notes/kent-beck/rip-
tdd/750840194948847)?

Does every element that exists on facebook.com get assigned a unique string
like the one above?

~~~
evunveot
Basically, the "/kent-beck/rip-tdd" portion is for humans (and/or SEO), so
that we can look at the URL and have some idea of what it is, and the
"750840194948847" is for their server to figure out what to actually show. You
can change the for-humans part to whatever you want and still see the same
note:
[https://www.facebook.com/notes/foo/bar/750840194948847](https://www.facebook.com/notes/foo/bar/750840194948847)

The advantage of only looking at the number is that if Kent Beck's name
changes or the title of the note changes, they can just start linking to a new
URL with a changed human-part (but the same numeric identifier) and the old
URL will still work. The "correct" way to do it would be to track and validate
every version of the human-part for every URL, redirect old versions to the
newest version, and 404 made-up ones. But in a way that would be slightly
inconveniencing human users following outdated links by making their browsers
follow a redirect when really only search engine spiders care whether there's
a single canonical URL per page, so if Facebook has given it any thought, they
probably decided just to not bother.

And at their scale, keeping track of one or more string URL versions for each
page (that is, each piece of URL-addressable content that makes sense to have
some kind of title slug included) would be non-trivial. Billions and billions
of URLs to track, dubious benefit.

------
barce
This is simply crazy talk. He creates a list of genuine issue, e.g. over-
engineering and slaps them under the moniker of "because TDD."

I don't know how many times production was saved because there was an
automated test written via TDD that prevented bad code from going out. Too
many times to count.

What the author is suggesting is to throw this out and go back to the days of
broken production apps are okay. This has never bothered Facebook, and it will
definitely bother engineers who want to take pride in their work.

~~~
aaimnr
It's sarcasm.

------
raverbashing
Which is funny

"Over-engineering. I have a tendency to "throw in" functionality I "know" I'm
"going to need". Making one red test green (along with the list of future
tests) helps me implement just enough. I need to find a new way to stay
focused."

So creating a test for a function that sum of numbers that gets 1 and 1 and
returning a hardcoded 2 is "just enough" and " a great way to stay focused ",
funny

I kind of agree with the other points, not so much about the "API design"
stuff, while it's true it facilitates, the end word is with the main API user.

Well, I'm glad it's dead, now I don't have to spend time mocking all other
parts of my program.

------
axanoeychron
Could testing preconditions and expectations of OpenSSL rooted out Heartbleed
and the the Safari goto gaffe? Those bugs were process orientated - not
cryptographic algorithm failures.

I think now is an important time as ever for TDD. (Test your expectations! You
might be surprised or even wrong. Do not underestimate your hubris when it
comes to introducing bugs.)

------
chris_wot
A knee-jerk reaction to an article that could cause many to have knee-jerk
reactions against TDD? How appropriate.

------
shitgoose
Who is stopping Kent from continuing using TDD techniques? Since when IT
became a GULAG?

------
DanielBMarkham
Another month, another Agile war. Is it co-location? Nope. Is it SAFe? Nope.
Looks like TDD. Again.

1) People make money on these wars. Do not waste your time on them.

2) Out of all the Agile stuff I've ever come across, TDD is the thing that
drives most people nuts. I think because it's something that has to do with
your minute-to-minute work. I'm a fan -- when it's appropriate (not in
startups). But dang, people go crazy about it.

3) TDD is more about the way we approach doing a thorough job than it is about
programming. At least in my mind. It's double-entry bookkeeping for coding.
Not only did you do it, but it's cross-checked. Therefore, just like good
accounting practices, it makes sense to a lot of people. It's also annoying as
hell to a lot of people. This set probably overlaps.

------
andyl
TDD advocates: build a new framework that extends Rails, one that makes it
easy to add service layers and fast tests.

IMHO fat models are the new PHP, and giant classes suck. Its time for new
conventions to emerge.

Prove DHH wrong with working code, not blog posts or books or conference
talks.

~~~
tzaman
You don't need a new framework to easily add service layers and fast tests.
That comes with some proper planning before writing the code. And the
conventions are there for decades as well, developers just need to be aware of
them a bit more.

------
spaznode
What-the-fuck-ever

To the whole article. I read the dhh article, Kent did not. The people
practicing umm "agility" did a better job handling some of the root issues DHH
brought up.

~~~
rimantas
Strange to see you being downvoted. I think many commenting did not read the
article and did not the video
([http://www.justin.tv/confreaks/b/522089408](http://www.justin.tv/confreaks/b/522089408)
fast-forward to 10:30). DHH does not argue agains testing, his argument is
against cargo-culting and hurting the design in pursue of faster testing and
more coverage, even when it is usless. DHH even quotes Kent himself in the
talk: "I get paid for code that works, not for tests, so my philosophy is to
test as little as possible to reach a given level of confidence".

~~~
beat
Indeed. I think DHH was very specific in his criticism, that for _controllers
only_ , then _TDD and unit tests_ aren't the wisest choice, because they
introduce complexity and potential problems (really, are you sure all those
mocks catch all your edge cases?).

The critics, including Kent Beck here, have by and large reducto absurdum'd it
to "DHH HATES TESTING AND EATS BABIES", which isn't his point at all. Sure,
DHH could have been more narrowly focused and less confrontational in his
language, but that doesn't mean he's wrong.

Look at it this way... are controllers hard to test _in Rails_ , or are
controllers hard to test _in general_? This is an argument for lightweight
controllers that are little more than routing glue (don't put business logic
in controllers), and then giving them a pass on unit testing in order to keep
them clean.

This gets to something I've been chewing on and should write about, which I
think of as Tautology Testing. It's endemic in excessive unit testing. You
create a mock so you can create a test so a test exists. The test doesn't
really _test_ anything except its own existence. How is that useful? You're
just adding complexity, not functionality.

~~~
djur
Perhaps DHH could have chosen a better title for his post than "TDD is dead",
then? Perhaps "unit testing for controllers: not the wisest choice"?

~~~
Shebanator
DHH's article looks to be titled 'Test-induced design damage', not 'TDD is
dead'. 'TDD is dead' is referenced in the article as a current uprising (which
I hadn't heard of, fwiw), not necessarily as something DHH personally
believes. I thought his take on the issue was nuanced and thoughtful, so its
surprising to see Kent's overreaction here.

~~~
djur
"TDD is dead. Long live testing."[1]

[1]: [http://david.heinemeierhansson.com/2014/tdd-is-dead-long-
liv...](http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-
testing.html)

------
sergiotapia
Why aren't these quips written as comments in the main DHH article submission?
Everybody has to whore themselves out these days - embarrassing.

~~~
mbillie1
It's possible that, since this was written on FB and not Kent's blog (
[http://www.threeriversinstitute.org/blog/](http://www.threeriversinstitute.org/blog/)
), that this wasn't intended for as public an audience as HN and was not an
attempt to "whore himself out."

~~~
pigs
He did tweet about it:
[https://twitter.com/KentBeck/status/461175937892356096](https://twitter.com/KentBeck/status/461175937892356096)

~~~
mbillie1
Ah, missed that. Well, fair points then :)

