8 ms·
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.
- lvh 12y agoI can't find the summary. This appears to be a link to the videos themselves.
- heroprotagonist 12y agoYou need to click the 'more...' button at the bottom of each topic to see the summary.
- mistermann 12y agoWow, thanks for that....what a terrible UI presentation.
- romanovcode 12y agoNo.[0] [0] http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines
- phpnode 12y agohttps://news.ycombinator.com/item?id=4722251 https://news.ycombinator.com/item?id=4722251
- tempodox 12y agoI disagree. Betteridge's law is useful.
- Sarien 12y agoIt 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 12y agoIt'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.
- biot 12y agoI think you meant to say: "Is Betteridge's law useful?"
- mantraxD 12y agoWell. 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 12y agoWell, 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 12y agoAutomated tests are awesome but they aren't useful in all cases and it doesn't always make sense to write them first.
- deleted 12y ago[deleted]
- tpatke 12y agoMy 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.
- bloodmoney 12y agoI don't know about your code quality assertion. My experience has been that it produces code right off the bat that is equivalent to code that has been through 1 or 2 rounds of functional testing. I ignore code coverage, though. It's not a good metric.
- jpollock 12y agoMy personal experience is that any code that I write that I haven't tested has a bug in it. Usually a NPE/SegFault.
- kylebrown 12y agoWhenever I tried to learn TDD, it only seemed relevant for back-end testing (eg REST APIs). But is there anyone left who is strictly a back-end guy? Most programmers now bill themselves as full-stack app developers, and probably spend at least half their time working on the front-end/UI. I hadn't heard of functional testing before. From a stackoverflow answer: > Functional Tests are written from the user's perspective. They ensure that the system is functioning as users are expecting it to. This makes much more sense to me than TDD. TDD is writing functions which test other functions. Are the users writing code, and passing arguments to function calls? If not, then time spent on TDD isn't adding much value for the users. So what does it mean to write functional tests? I'd argue that writing modular React components is a form of functional testing. Devcards[1] is similar, and looks to me exactly like what would be considered functional testing. These two workflows feel much more natural than testing UIs methods like automated selenium browser interactions to generate screenshots. 1. http://rigsomelight.com/2014/06/03/devcards-taking-interactivity-to-the-next-level.html http://rigsomelight.com/2014/06/03/devcards-taking-interacti...
- manishsharan 12y agoI 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!
- BorgHunter 12y agoUnit tests are only partly to prove your code works when you initially write it, though. They also have significant value in allowing others—or Future You—the confidence to touch nearby code without feeling scared of breaking things. This is very important in Java and similar languages; in Clojure I suspect¹ this is less important just because functional styles lend themselves better to obviously-correct code. ¹Disclaimer: I have no experience with Clojure, working primarily in Scala these days. I do aim for good unit test coverage in Scala just the same as I did when I worked in Java.
- alextp 12y agoI write tests not to convince myself my code is correct (it often is, and repl and ad-hoc testing are more than enough to make sure it does the right thing now) but to prevent myself & future others from breaking it as they maintain it in the future.
- wpietri 12y agoA 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.
- aardvark179 12y agoThe problem with that style of testing at the repl is it proves your code worked for those tests at that time, but unless you turn that into test cases that will keep on being run then there's a good chance that you'll forget one of those test cases in the future. Trust me, a large, old, code base like that is terrifying to work with. Don't obsess over code coverage though, concentrate on areas of risk and scenarios, I've written code with 100% coverage that still had an exciting range of bugs, and I've seen extremely robust code that had relatively low coverage overall but had tests focusing on the really tricky areas.
- gress 12y agoSpecifying 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.
- spion 12y agoSoftware 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-1228640 https://gist.github.com/dhh/4849a20d2ba89b34b201#comment-122...
- logfromblammo 12y agoWas 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 12y agoFor 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 12y agoThat 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 12y agoDamn - 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?
- mavdi 12y agoINSERT STUPID ATTENTION GRABBING HEADLINE
- josephlord 12y agoIn 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 12y agoBurying as dupe. https://hn.algolia.com/?q=is+tdd+dead#!/story/sort_by_date/0/is%20tdd%20dead https://hn.algolia.com/?q=is+tdd+dead#!/story/sort_by_date/0...