7 ms·

RIP TDD

122 points by platz 13y ago

jshen 13y ago
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 13y ago
  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.
  - SoftwareMaven 13y ago
    I think you mis-characterize people's concern for pair programming and open workspaces. That alone makes me wonder how objectively you can look at this topic. TDD has become a foundational tenet of agile, so any criticisms of it naturally get seen as a criticism of agile (similar to open spaces and pair programming). There's more than one way to skin a cat, and it isn't always fear of change that keeps people from changing.
    - bowlofpetunias 13y ago
      > TDD has become a foundational tenet of agile Dear god, please take the straw man out back and shoot him already. There really is no way to have an intellectually honest discussion about these subjects, is there?
    - Jtsummers 13y ago
      > TDD has become a foundational tenet of agile When I see "agile" and "tenet" in the same sentence, I think "government shop". An explicitly flexible premise (Agile) does not have "one true way" to do anything.
  - spamizbad 13y ago
    > 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)
    - kasey_junk 13y ago
      And I've worked in TDD shops for years and never seen the fanatical TDD devotee. I have seen lots of developers that will use any excuse they can find not to provide automated tests for their code.
    - mbillie1 13y ago
      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 13y ago
        You probably got lucky. But yeah, they exist
      - deleted 13y ago
        [deleted]
    - agentultra 13y ago
      I've seen code bases designed from the tests first and they were pleasant to work with. I've worked jobs where it was my responsibility to salvage undocumented, untested legacy code and extend it with new features while keeping it running. The truth is rarely in the extremes being characterized in these blog posts and discussion threads. The only kind of test code I've seen that required far too many mocks and dependency injections tend to result from poor design choices and writing the tests after the functionality. If TDD as a practice doesn't work for you, that's fine -- but I think it's disingenuous to offer no alternatives. Integration testing isn't an alternative; I use them in concert with a well tested code base. And I use whole-system tests too. DHH works in a small corner of the field. TDD may not work well for Rails applications is all I've been able to glean from his posts. I think that's a battle for the Ruby/Rails community to have. It doesn't discredit TDD one bit.
  - scrozier 13y ago
    I've met plenty of these devotees. I'm not sure that they practice what they preach, but I have felt the wrath of their judgment, to the point that I hate "admitting" that I don't believe in TDD. I, for one, am pleased that DHH has made my world a little brighter.
    - mbillie1 13y ago
      > I have felt the wrath of their judgment, to the point that I hate "admitting" that I don't believe in TDD I'm not sure if you're exaggerating a little, but I think that having colleagues whose wrath makes you hesitant to express yourself is an entirely different issue from that of test-driven development or not. Development is a fairly easy field in which to demonstrate that you're at least as correct in your methodologies as another developer: just produce quality code. This feels (as these arguments very often feel to me) like a personality issue more than a methodological one.
  - _random_ 13y ago
    "For an enormous majority of the wider development community" => noise generated does not equal the size of the community.
- tolas 13y ago
  Agreed. It is interesting how "up in arms" so many people are getting. I've never used TDD and have been very successful both in the startup world and enterprise world. I used to think I was "inferior" and had to keep quite about my lack of TDD. At least DHH has "put a voice" to our kind. I span that weird space between product and engineering though. So most of the time I'm hacking in something like "prototype" mode, so TDD just makes no sense. I approach it more like sculpting. I'm slowing hacking away at this block of marble to produce an elegant "beautiful" product. Once it start to take shape I can create tests and specs to define the learnings and creations that I've made. Tests first? It just doesn't work for me.
  - axanoeychron 13y ago
    Indeed. However this doesn't mean that TDD is dead - which is what a lot of people who do not like TDD seem to believe. I know you might not have said this but this whole movement is misguided. If anything, if the adherents of TDD were to properly abandon it, then that would be TDD dying because they would have come up with something better or moved on.
- pessimizer 13y ago
  I'm not 100% sure that this post is supposed to be sarcastic (although I am about 60% sure.) The issues are certainly legitimate, and TDD does define one approach (of many possible approaches) for mitigating them.
vinkelhake 13y ago
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".
- endersshadow 13y ago
  Well, you see, we've wandered into a dogmatic war. This is like the early days of Vim vs Emacs. There will be thousands upon thousands of words expended, because being verbose means you're right. Nobody will listen to the other side because they're convinced they're right. We'll also see strawman effigies burned to the ground, and one side claiming victory because of it. I feel that this is long from over.
- anon1385 13y ago
  >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…
spaznode 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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"?
revscat 13y ago
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 13y ago
  "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.
  - rhizome 13y ago
    To be sure, "negative" is the weak point in the statement/sentiment. It's a value judgement subject to where the person is drawing a line between the goods and the bads (methodology always unstated), so the argument wallows in indeterminacy. As long as people throw out a simple "the real issue" without explaining what they mean by it, it's inevitable. Pretty soon, every player is talking past one another, someone writes a blog post purporting to lay out the landscape of all sides, someone counters rap-battle style, someone else posts to HN "Ask HN: your favorite reasons to TDD," which provides the foundation for an ebook, after which three people post "Show HN: site to plan an optimal TDD strategy." After that, we wait for someone to posit a successor and the cycle starts over again.
  - barrkel 13y ago
    "Testability" tends to add unnecessary (by KISS) configurability and indirection to code composed out of sub-units. Because a testable unit of code must have its inputs and collaborators controlled, all the inputs and collaborators need to be configurable or replaceable, even when such configuration is unnecessary to the business value aimed at. In statically typed languages like Java, this tends to exhibit as a proliferation of interfaces that only have a single implementation, namespaces with too many identifiers publicly exposed, and lots of open extension points - which hurts versioning. It tends towards requiring complex IoC controllers with associated config. Code ends up filled with boilerplate glue and over-abstraction (factory-factories etc.), and much harder to read because IDEs can no longer follow the link between a method call and its implementation - because the method call is all too often dynamically resolved via an interface implementation.
sergiotapia 13y ago
Why aren't these quips written as comments in the main DHH article submission? Everybody has to whore themselves out these days - embarrassing.
- mbillie1 13y ago
  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 13y ago
    He did tweet about it: https://twitter.com/KentBeck/status/461175937892356096 https://twitter.com/KentBeck/status/461175937892356096
    - mbillie1 13y ago
      Ah, missed that. Well, fair points then :)
    - sergiotapia 13y ago
      I rest my case.
platz 13y ago
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 13y ago
  Is this the podcast? http://www.functionalgeekery.com/episode-8-jessica-kerr/ http://www.functionalgeekery.com/episode-8-jessica-kerr/ /downloads
  - platz 13y ago
    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.
projectileboy 13y ago
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 13y ago
  He has books and lectures on the subject so I'm not sure he has much more to say.
chris_wot 13y ago
A knee-jerk reaction to an article that could cause many to have knee-jerk reactions against TDD? How appropriate.
andyl 13y ago
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.
- mbillie1 13y ago
  > Prove DHH wrong with working code, not blog posts or books or conference talks. I completely agree; I will only say that it actually is quite easy to add service layers and fast tests to Rails applications - you just don't stick everything inside ActiveRecord like DHH would like you to :)
- tzaman 13y ago
  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.
- programminggeek 13y ago
  I did this about a year ago, but doesn't really extend or care about rails at all. http://obvious.retromocha.com http://obvious.retromocha.com The only "framework" part that you need outside of some reasonable OOP design principles is some amount of type checking to enforce some notion of boundaries. Ruby is super weak in this area, so I added some bits to do that. For the record, until you experience the trouble that the MVC Big Ball of Fat Models or Controllers gets you to, you probably won't have much appreciation for the service/command style or the hexagonal ports/adapters style. At least, that's been my experience with other developers.
axanoeychron 13y ago
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.)
shitgoose 13y ago
Who is stopping Kent from continuing using TDD techniques? Since when IT became a GULAG?
raverbashing 13y ago
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.
deleted 13y ago
[deleted]
DanielBMarkham 13y ago
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.
deleted 13y ago
[deleted]
gregors 13y ago
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 13y ago
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/750840194948847 https://www.facebook.com/notes/kent-beck/rip-tdd/75084019494...? Does every element that exists on facebook.com get assigned a unique string like the one above?
- evunveot 13y ago
  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 13y ago
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 13y ago
  It's sarcasm.
Arkadir 13y ago
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.

122 points by platz 13y ago

jshen 13y ago

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 13y ago
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.
- SoftwareMaven 13y ago
  I think you mis-characterize people's concern for pair programming and open workspaces. That alone makes me wonder how objectively you can look at this topic. TDD has become a foundational tenet of agile, so any criticisms of it naturally get seen as a criticism of agile (similar to open spaces and pair programming). There's more than one way to skin a cat, and it isn't always fear of change that keeps people from changing.
  - bowlofpetunias 13y ago
    > TDD has become a foundational tenet of agile Dear god, please take the straw man out back and shoot him already. There really is no way to have an intellectually honest discussion about these subjects, is there?
  - Jtsummers 13y ago
    > TDD has become a foundational tenet of agile When I see "agile" and "tenet" in the same sentence, I think "government shop". An explicitly flexible premise (Agile) does not have "one true way" to do anything.
- spamizbad 13y ago
  > 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)
  - kasey_junk 13y ago
    And I've worked in TDD shops for years and never seen the fanatical TDD devotee. I have seen lots of developers that will use any excuse they can find not to provide automated tests for their code.
  - mbillie1 13y ago
    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 13y ago
      You probably got lucky. But yeah, they exist
    - deleted 13y ago
      [deleted]
  - agentultra 13y ago
    I've seen code bases designed from the tests first and they were pleasant to work with. I've worked jobs where it was my responsibility to salvage undocumented, untested legacy code and extend it with new features while keeping it running. The truth is rarely in the extremes being characterized in these blog posts and discussion threads. The only kind of test code I've seen that required far too many mocks and dependency injections tend to result from poor design choices and writing the tests after the functionality. If TDD as a practice doesn't work for you, that's fine -- but I think it's disingenuous to offer no alternatives. Integration testing isn't an alternative; I use them in concert with a well tested code base. And I use whole-system tests too. DHH works in a small corner of the field. TDD may not work well for Rails applications is all I've been able to glean from his posts. I think that's a battle for the Ruby/Rails community to have. It doesn't discredit TDD one bit.
- scrozier 13y ago
  I've met plenty of these devotees. I'm not sure that they practice what they preach, but I have felt the wrath of their judgment, to the point that I hate "admitting" that I don't believe in TDD. I, for one, am pleased that DHH has made my world a little brighter.
  - mbillie1 13y ago
    > I have felt the wrath of their judgment, to the point that I hate "admitting" that I don't believe in TDD I'm not sure if you're exaggerating a little, but I think that having colleagues whose wrath makes you hesitant to express yourself is an entirely different issue from that of test-driven development or not. Development is a fairly easy field in which to demonstrate that you're at least as correct in your methodologies as another developer: just produce quality code. This feels (as these arguments very often feel to me) like a personality issue more than a methodological one.
- _random_ 13y ago
  "For an enormous majority of the wider development community" => noise generated does not equal the size of the community.
tolas 13y ago
Agreed. It is interesting how "up in arms" so many people are getting. I've never used TDD and have been very successful both in the startup world and enterprise world. I used to think I was "inferior" and had to keep quite about my lack of TDD. At least DHH has "put a voice" to our kind. I span that weird space between product and engineering though. So most of the time I'm hacking in something like "prototype" mode, so TDD just makes no sense. I approach it more like sculpting. I'm slowing hacking away at this block of marble to produce an elegant "beautiful" product. Once it start to take shape I can create tests and specs to define the learnings and creations that I've made. Tests first? It just doesn't work for me.
- axanoeychron 13y ago
  Indeed. However this doesn't mean that TDD is dead - which is what a lot of people who do not like TDD seem to believe. I know you might not have said this but this whole movement is misguided. If anything, if the adherents of TDD were to properly abandon it, then that would be TDD dying because they would have come up with something better or moved on.
pessimizer 13y ago
I'm not 100% sure that this post is supposed to be sarcastic (although I am about 60% sure.) The issues are certainly legitimate, and TDD does define one approach (of many possible approaches) for mitigating them.

vinkelhake 13y ago

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

endersshadow 13y ago
Well, you see, we've wandered into a dogmatic war. This is like the early days of Vim vs Emacs. There will be thousands upon thousands of words expended, because being verbose means you're right. Nobody will listen to the other side because they're convinced they're right. We'll also see strawman effigies burned to the ground, and one side claiming victory because of it. I feel that this is long from over.
anon1385 13y ago
>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…

spaznode 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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"?

revscat 13y ago

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 13y ago
"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.
- rhizome 13y ago
  To be sure, "negative" is the weak point in the statement/sentiment. It's a value judgement subject to where the person is drawing a line between the goods and the bads (methodology always unstated), so the argument wallows in indeterminacy. As long as people throw out a simple "the real issue" without explaining what they mean by it, it's inevitable. Pretty soon, every player is talking past one another, someone writes a blog post purporting to lay out the landscape of all sides, someone counters rap-battle style, someone else posts to HN "Ask HN: your favorite reasons to TDD," which provides the foundation for an ebook, after which three people post "Show HN: site to plan an optimal TDD strategy." After that, we wait for someone to posit a successor and the cycle starts over again.
- barrkel 13y ago
  "Testability" tends to add unnecessary (by KISS) configurability and indirection to code composed out of sub-units. Because a testable unit of code must have its inputs and collaborators controlled, all the inputs and collaborators need to be configurable or replaceable, even when such configuration is unnecessary to the business value aimed at. In statically typed languages like Java, this tends to exhibit as a proliferation of interfaces that only have a single implementation, namespaces with too many identifiers publicly exposed, and lots of open extension points - which hurts versioning. It tends towards requiring complex IoC controllers with associated config. Code ends up filled with boilerplate glue and over-abstraction (factory-factories etc.), and much harder to read because IDEs can no longer follow the link between a method call and its implementation - because the method call is all too often dynamically resolved via an interface implementation.

sergiotapia 13y ago

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

mbillie1 13y ago
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 13y ago
  He did tweet about it: https://twitter.com/KentBeck/status/461175937892356096 https://twitter.com/KentBeck/status/461175937892356096
  - mbillie1 13y ago
    Ah, missed that. Well, fair points then :)
  - sergiotapia 13y ago
    I rest my case.

platz 13y ago

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 13y ago
Is this the podcast? http://www.functionalgeekery.com/episode-8-jessica-kerr/ http://www.functionalgeekery.com/episode-8-jessica-kerr/ /downloads
- platz 13y ago
  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.

projectileboy 13y ago

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 13y ago
He has books and lectures on the subject so I'm not sure he has much more to say.

chris_wot 13y ago

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

andyl 13y ago

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.

mbillie1 13y ago
> Prove DHH wrong with working code, not blog posts or books or conference talks. I completely agree; I will only say that it actually is quite easy to add service layers and fast tests to Rails applications - you just don't stick everything inside ActiveRecord like DHH would like you to :)
tzaman 13y ago
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.
programminggeek 13y ago
I did this about a year ago, but doesn't really extend or care about rails at all. http://obvious.retromocha.com http://obvious.retromocha.com The only "framework" part that you need outside of some reasonable OOP design principles is some amount of type checking to enforce some notion of boundaries. Ruby is super weak in this area, so I added some bits to do that. For the record, until you experience the trouble that the MVC Big Ball of Fat Models or Controllers gets you to, you probably won't have much appreciation for the service/command style or the hexagonal ports/adapters style. At least, that's been my experience with other developers.

axanoeychron 13y ago

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

shitgoose 13y ago

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

raverbashing 13y ago

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.

deleted 13y ago

[deleted]

DanielBMarkham 13y ago

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.

deleted 13y ago

[deleted]

gregors 13y ago

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 13y ago

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/750840194948847 https://www.facebook.com/notes/kent-beck/rip-tdd/75084019494...? Does every element that exists on facebook.com get assigned a unique string like the one above?

evunveot 13y ago
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 13y ago

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 13y ago
It's sarcasm.

Arkadir 13y ago

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.