TDD did not live up to expectations

https://blogs.msdn.microsoft.com/ericgu/2017/06/22/notdd/

by kiyanwang • 9 years ago

586 433 9 years ago

blogs.msdn.microsoft.com

dyarosla• 9 years ago

tl;dr: TDD is not, on its own, effective. If code is highly coupled, tests become highly coupled and a nightmare. The author advocates that learning to properly refactor and create low-coupled code should be a first priority ahead of following TDD blindly.

IMO, nothing really profound here.

tonyedgecombe2• 9 years ago

It's interesting where this leads you though, deep into dependency injection, inversion of control containers and patterns like MVVM.

I'm not saying these things are bad but they do have a cost.

eropple17• 9 years ago

It doesn't necessarily lead you there at all. "Dependency injection" is a fancy phrase for "pass stuff a function needs into the function", only it does so by adding state to objects where that state probably shouldn't exist. You don't have to faff around with IoC or MVVM to properly isolate dependencies; indeed, it's the core idea behind something like Gary Bernhardt's "Functional Core, Imperative Shell" (which, if you're not understanding this instinctively, makes me fear for your code):

https://www.destroyallsoftware.com/talks/boundaries

https://www.destroyallsoftware.com/screencasts/catalog/funct...

lgunsch6• 9 years ago

Very true. Even Robert Martin himself says that TDD without refactoring is worse than TDD (in one of his books). He mentions that if refactoring is not done you will be worse off than had you not done tests at all. He even recommends simply deleting all the tests.

AnimalMuppet2• 9 years ago

If code is highly coupled, tests become highly coupled and a nightmare.

TDD is supposed to prevent that. What's supposed to happen is, if the test is hard to write, it's telling you something. You're supposed to pay attention to that pain. It's supposed to show you that your code is highly coupled, and make you fix that.

If you just go ahead and write the test, difficult as it is, instead of finding a way to refactor to clean up the coupling, then yes, TDD produces a nightmare of a test. That's because you're not doing it right, though.

(Yes, I recognize that this is a lot like a No True Scotsman. But in fact any methodology, practiced badly, will produce sub-optimal results...)

austenallred2• 9 years ago

The problem with TDD is that we flawed humans are writing the tests in the first place. If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code.

I use it on occasion as a good sanity check to make sure I didn't break anything too obvious, but this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place.

_puk• 9 years ago

"I use it on occasion as a good sanity check to make sure I didn't break anything too obvious"

That sounds more like unit tests than TDD. With TDD you should already know that you didn't break anything..

If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input; it is not however going to determine if you did that in the best possible way.

eropple17• 9 years ago

This is a good and cool post. TDD is less susceptible to "sucky code" for two reasons:

1) It should be a direct port of your specification. If you don't have a specification, you can't do TDD.

2) It should be written by someone who won't be writing the code. Or, at minimum, checked over by someone who won't be writing the code.

Writing tests after you've written code strongly encourages you to write implementation tests rather than specification tests. Both are important and useful, but for separate things (if you have to change your specification tests it's probably because you need to bump a minor or major version number for your software).

falcolas4• 9 years ago

If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input

Well, if you suck at writing code, what guarantees do you have that the tests (which are also code you write) are even correct?

buttscicles• 9 years ago

this idea that TDD is a panacea where no bugs ever survive

I don't think I've heard many people claim that. Rather the point I've seen made is that it not only ensures you've got tests, doing them up front encourages developers to write code in a way that is easy to test, which usually happens to be higher quality, more loosely coupled code.

When it comes to writing code there are no silver bullets, TDD included.

fmoralesc• 9 years ago

The problem win TDD is that we flawed humans are writing the tests in the first place.

A general AI could have the same kind of problem, and if we had specialized AIs, we could presumably create the target software directly anyway...

Ace172• 9 years ago

If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code.

Actually, there is ; providing the difficulty is algorithmic. Take "sort", for example.

// test code

assertEquals([1,2,3,4,5], sort([4, 1, 2, 3, 5]))

// production code

int[] mySort(int[] list)

{

  // TODO: implement a sorting algorithm here.

}

Any programmer could write a fairly good test suite for "sort". However, I highly doubt they could write the implementation.

Of course, this is a very simple example.

Most of the times, the difficulty lies in finding the proper interface between test and production code. And there, there's no way to compensate for poor software design skills. Actually, forcing bad software designers to test the code they write might even worsen the situation, by rigidifying poorly-designed-wannabe-interfaces.

this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place.

This is the software industry ; new techniques are confused with silver bullets!

strictnein• 9 years ago

"Any programmer could write a fairly good test suite for "sort". However, I highly doubt they could write the implementation."

I mean, any developer should be able to write a sort. They might end up with some O(2^n) behemoth, but they should be able to do it.

dragonwriter3• 9 years ago

this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place.

I've literally never encountered this idea, in person or otherwise, from anyone advocating TDD, only as a an argument TDD opponents like this attack. I'm not sure if it's a rare argument they've latched onto, a common misunderstanding of the purpose of TDD, or an outright strawman, but it's certainly not the main argument (or one of them) I've seen for TDD.

TDD:

1. Validates that you have a reasonably clear operational understanding of the intended behavior (but not completeness), forcing more questions out early and preventing some portion of the waste of code aimed at something that isn't the intended functionality that would otherwise occur, and

2. Assures that automated tests (which are often most valuable for regression testing later changes) actually get written, which is a significant issue in practice with test-last processes.

bluGill8• 9 years ago

this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place.

The idea only exists as a straw man for those trying to attack TDD.

TDD doesn't ensure there are no bugs. TDD ensures that everything you can think of that can go wrong does not, even as you think of new ways something could go wrong and fix that.

I was in one job a few years back without tests. We had a case where someone got a bug which was easy to fix, but they didn't realize their fix broke something else. Then we released and got the bug report which was fixed by reverting back to the original bug - we went through 3 rounds (over 6 years - a different contractor on the bug each time so who didn't realize what was going on) before someone realized what was happening and fixed both bugs.

gkop• 9 years ago

There are at least several other advantages to TDD the article misses:

* Faster development feedback loop by minimizing manual interactions with the system

* The tests are an executable to-do list that guides development, helping you stay focused and reminding you what the next step is

* Provides a record of the experimentation taken to accomplish a goal, which is especially useful when multiple developers collaborate on work-in-progress

thinkingkong• 9 years ago

Except in order to have a checklist you have to have your design and implementation up front which is out of reach for most developers.

If were testing high level results in multiple cases thats cool. But a lot of the time youre going to try different approaches that may modify or involve changing your output.

hyperpallium2• 9 years ago

TDD is waterfall

s73ver6• 9 years ago

No you don't. You just need to know what the unit you're currently working on does. And if you're working on it, you should know what it does. If you don't, that's a sign that maybe you need to have a conversation with someone.

falcolas4• 9 years ago

The tests are an executable to-do list that guides development

So what generates the to-do list when you're building out the tests (arguably the harder of the two tasks, when the tests drive the design).

Provides a record of the experimentation taken to accomplish a goal

If you're doing a proper refactor cycle, those tests will vanish (or change) as the code evolves. You're back to relying on your source control, which provides the benefit with or without tests.

There are benefits to TDD; these two are not among them IMO.

lojack• 9 years ago

So what generates the to-do list when you're building out the tests (arguably the harder of the two tasks, when the tests drive the design).

I don't necessarily use tests as a todo list like gkop, but for me at least... my first tests usually come from acceptance criteria if available, or some sort of business requirements. They usually end up being my feature or integration tests.

wyldfire• 9 years ago

Sorry for the aside but I find it humorous that the headline that should read "TDD--, Refactoring++" instead shows "TDD—, Refactoring++".

This is emblematic of that frustrating AutoFormat behavior that replaces double dashes with an emdash. Probably not a coincidence that this appears on MSDN -- perhaps it was drafted on Outlook or Office or some other tool w/this same AutoFormat.

This feature is responsible for countless miscommunications between colleagues à la "I copied and pasted your command just as you had it in the email"...

austenallred2• 9 years ago

Someone should have written a test to check for that

atonse2• 9 years ago

In the earlier days of the ruby community, I feel TDD was seen as gospel. And if you dared say that TDD wasn't the way (which I always felt), you'd feel like you were ostracized (update: just rewording to say, you'd worry that it would hurt you in a job search, not that people were mean to you). So I never spoke up. I feel like I was in the TDD-bad closet.

I absolutely think _tests_ are useful, but have never found any advantages to test-DRIVEN-development (test-first).

But part of that is probably my style of problem solving. I consider it similar to sketching and doodling with code until a solution that "feels right" emerges. TDD severely slows that down, in my experience, with little benefit.

What I've found works really well is independently writing tests afterwards to really test your assumptions.

jcbrand• 9 years ago

My experience is that whether one is writing tests first or not, the code that is being written does get tested one way or the other.

In other words, people (for example web-devs) who don't write tests first tend to "test" their code by clicking around in the browser to see whether they get the desired effect.

Writing tests, running them and then iteratively updating/fixing the code is IMO so much more efficient than manually clicking around to test one's code.

sbov• 9 years ago

Clicking around in your browser is more akin to an integration test though. TDD is about unit tests, not integration tests.

wolco3• 9 years ago

You will miss items if you don't visually inspect even in a ttd application. Tdd is a net to catch some expected bugs but should not be the only tests.

stale20022• 9 years ago

Exactly this!

It is literally faster to write the test, then to manually go around hitting your endpoint.

felipeccastro• 9 years ago

Agreed, but I would add there are specific scenarios where doing the test first really helps - when you're building a routine complex enough that you can't think upfront how you'll do it, like a complex calculation for example. In that case, at least thinking about the tests first and making one by one pass helps you breaking down the problem into smaller, easier parts.

spdionis2• 9 years ago

This is the best situation for a TDD workflow, and the only situation I myself use TDD in.

If you have complex calculations or data transformations or you know well the expected input and output of what you're trying to do TDD actually speeds you up by allowing you to iterate faster on your solution.

If you're writing glue code between a number of other application components (90% of development in web backends) then TDD loses a lot of benefits.

heifer28222• 9 years ago

I think TDD helps or doesn't help depending on the circumstances. The problem is the people who claim there's One True Way.

For instance, if you were working on a big app and there was a bug, writing a failing test for that bug and then looking into the fix is very helpful. But if you're starting a new project from scratch with loose requirements, or worse yet, building a prototype, starting with tests would be a waste of time at best.

moron4hire5• 9 years ago

if you were working on a big app and there was a bug, writing a failing test for that bug and then looking into the fix is very helpful.

Well, first of all, that's not TDD. TDD is Test-Driven Development. In your scenario, you wrote the test after the code in question. In TDD, the whole point is to write the test before the code in question.

So the value in your scenario is only insofar as the test is a useful way to quickly exercise the code in question. For example, if we have some sort of customer-facing website and there is a bug in how they save their user profile, it will be easier to test fixes to the problem if we don't have to go through the full flow of logging into the site, navigating to the profile, making edits, and clicking save all the time. But having an XUnit-style framework for running that test is not necessary for that.

moron4hire5• 9 years ago

Like the author in the original article, I used to be all about TDD. Now, I like to tell people that "I'm apostate in the ways of TDD". I specifically use the language of religion because I think strict adherence to TDD is itself a religion.

I somewhat disagree with the statement he makes, "we know that most developers do not have great design/refactoring skills". I've certainly worked at places that all but ordered me to never refactor code, and I suspect my experience is very far from unique. They thought "refactoring" was a made-up word that programmers used to cover up dicking around and wasting time. From a non-programmer's perspective, all they see is the programmer spending several hours with the end result being that nothing has visibly changed. Mind you, no visible changes is the ideal case for refactoring, so you have no easy means to explain why that is wrong.

He says that TDD only works if the programmer is good, but I think it's more the case that test-first only works in cases where we have very well-defined problems. For these TDD trainers that he's talking about, they've gone through the same problem set over and over again. For an experienced programmer, if you're encountering the same sorts of problems, you know what the pitfalls are and can look ahead, even if you aren't violating YAGNI, you can still do yourself some favors.

To put it to a specific metric, if you have a specification from which you're working, you basically have an answer sheet for your code. You can then write code that automatically verifies that your code matches that answer sheet. The more like "having a spec" your problem is, the more likely TDD will work very well for you.

But I don't do that kind of work very frequently. Most of my work is extremely experimental, fluid, and in a lot of ways, its behavior is arbitrary. Does a padding of 5px or 10px look better? Should the surface of a polygon be more or less smooth? Should running over the ground be 3m/s or 5m/s? Should the user have two hand tools that are identical, or should they be different tools? A lot of it has to be visually verified, because it would otherwise require a computer vision algorithm of some kind to know that the code I wrote to go from text to screen pixels worked correctly.

It's much more design than development, just that design is expressed in code rather than in Photoshop PSDs.

As a result, I focus much more on REPLs, saved REPL sessions, demo code, and making the iteration time between code change and test run as narrow as possible. What I think TDD provides (poorly) for people in this situation is this REPL-like behavior, in languages that don't particularly provide a good REPL (let us consider RoR a separate "language" from Ruby, in this case, as the expectations tend to be completely separate).

So if I'm writing an implementation of a rope data structure as part of a syntax highlighting text editor that renders into a WebGL texture, yeah, I have tests for that. Ropes and text editors are well-understood data structures, there's lots of information available about them, and there are right and wrong answers to what operations each should have and how they should behave. But that's not where the work ends. I still need to figure out how to let people interact with that text editor, be it with touch gestures or motion controllers or a keyboard or a gamepad or what have you, and that has no easy-mode.

andybak3• 9 years ago

Interesting that you mention REPLs. I wonder if the often maligned Python docstring concept has/had more merit than it is currently given credit for.

ericgunnerson9• 9 years ago

Article author here...

I'm pretty much in agreement with everything you wrote here, but I want reply to one thing you mentioned...

You somewhat disagreed with, "we know that most developers do not have great design/refactoring skills", because developers may have little chance to refactor. Totally on board with this; lack of understanding of technical debt and how it impacts a team's achievement is one of the biggest problems with software management.

But my point - which I clearly didn't make well enough - was that refactoring and design skills are really the same thing, and I've seen enough modified code to understand what the design skills of most developers are.

Joeri2• 9 years ago

They thought "refactoring" was a made-up word that programmers used to cover up dicking around and wasting time. From a non-programmer's perspective, all they see is the programmer spending several hours with the end result being that nothing has visibly changed.

The thing is, many refactoring efforts make code worse, not better. Refuctoring is something I've observed many times over, by people who consider themselves quite skilled at the art. The end result of their efforts is that the code is fancier or trickier, not more robust or easier to understand.

So, from a manager's perspective, how are you to discern between a programmer whose refactoring efforts save time down the road, and one whose efforts lose time down the road. Of course, normally you have technical leadership that can make this distinction and makes sure those people get a cold hard reality check, but many organizations discourage technical people from gaining enough power that they can stop other technical people in their tracks before they mess things up.

UK-AL4• 9 years ago

I find TDD very good implementing business rules on objects. Not so great experimentation on UI and presentation, which is what you seem to be doing.

You have to remember there a lot programmers out there, just implementing business rules into code.

stale20022• 9 years ago

"What I've found works really well is independently writing tests afterwards to really test your assumptions."

Sure. If you actually do it.

The problem with most companies, and the reason why I think that TDD 'works' is that it forces you to right some tests, any tests at all.

Many people, if they don't write the test first, will just end up not making any tests at all.

fran7118• 9 years ago

Exactly. I worked at a place where the majority of dev teams had little to no automated tests. Getting them to write tests was near impossible due to it 'taking too much time away from features and bug fixes'.

One team adopted TDD and forced themselves to do it for a year. They admitted it slowed their overall dev-cycle down a ton, but they ended up learning a lot about how to build a well designed API. I think more internal documentation about good design emerged from that then them evangelizing TDD.

Spivak• 9 years ago

If that's really the case then why not drop the ceremony and simply TTD to, "write some tests first."

raverbashing2• 9 years ago

Yes a lot of people kept parroting TDD (as most people parrot the latest fad without thinking for 3 seconds if they should actually do that)

I absolutely think _tests_ are useful, but have never found any advantages to test-DRIVEN-development (test-first).

Seconded. Especially the crap about "make the test fail first" (making the test fail is useful, especially if you're unfamiliar with some aspect of it), but it should not be an obligation

rsyntax• 9 years ago

Yeah I dislike that mantra, but I think it was a guideline for novice. I think the phrase should be updated to "make the test fallible".

UK-AL4• 9 years ago

The term making the test fail, isn't about explicitly making the test fail.

It's about the fact that it's not implemented yet, so of course it going to fail!

ehsanu1• 9 years ago

Especially the crap about "make the test fail first" (making the test fail is useful, especially if you're unfamiliar with some aspect of it), but it should not be an obligation

Sometimes I write code to fix a bug, then a test the tests my bugfix. Test passes. I'm done right? Well, I make sure my test fails without the bugfix. About half the time, the test still passes. ie I wasn't testing what I thought I was testing. That's why you make the test fail.

hinkley6• 9 years ago

I was quite comfortable with refactoring for a very long time before I started doing tests, and I think that colors my approach to the problem space. I write code until it misbehaves the first time, and then I start writing tests, comfortable in the knowledge that in another half hour this code will be unit testable and look better than what everyone else is turning in, and that I'll spend 20 minutes at the end cleaning it up even more.

But I am not everybody, and trying to set team policy on my comfort levels is quite likely a bit dangerous.

I've paired with a few smart people this month and was horrified by how they refactor. Most trust their hands more than the tools. They do a LOT of transcription instead of copy and paste, and don't use the IDE's refactoring tools at all. That's not just inviting human error to the table, that's giving it the seat of honor.

For most processes there are ways to do it that are worse than nothing at all, and unfortunately many of us seem drawn to them almost instinctively. I try not to think about it because it just makes me angry that the distance between what we collectively know and what we individually do is so wide.

thaumasiotes3• 9 years ago

They do a LOT of transcription instead of copy and paste

Transcription makes you think about what you're typing in and avoids the whole class of errors that arise from copy-and-paste. Transcribing code rather than pasting it is not a red flag.

reitanqild5• 9 years ago

What language?

ericgunnerson9• 9 years ago

Author here...

I have the same issue you have. I luckily work in a language with great refactoring tools, but it's like pulling teeth to get people to use them rather than cut and paste.

smokeyj• 9 years ago

I feel this way about code coverage (need that 100% badge).

If I took on a project with low quality and had a limited budget to ensure QA - I'd prioritize E2E testing over unit testing.

nickpsecurity8• 9 years ago

Here's you some evidence to use when you bring that up:

https://blog.regehr.org/archives/872

logfromblammo2• 9 years ago

Anecdotally, the cleanest, most maintainable code I have ever seen at work was the result of a TDD-mandatory project.

Equally anecdotally, that was the most efficient project management I have ever seen at my workplace.

Economically, our branch office was shuttered, and all employees laid off, just a few months after we delivered it, for almost entirely unrelated reasons. As it turns out, the only reason we did the TDD project at all is because our primary contract had not been renewed, and it was a lower-value contract. After it was done, we didn't have enough work left to do. But more importantly, the main office didn't have enough work to do, so they slurped up our dregs, kicked us to the curb, and sold themselves to a bigger company.

Perhaps the lead dev saw the writing on the wall, and wanted to make a showpiece to boost everyone's resumes. Perhaps he foresaw that one of the several companies we might end up with after the diaspora might get maintenance responsibilities, and that person shouldn't hate their former team for writing crappy, unmaintainable code. Doesn't matter. Did it once, and it turned out great.

I still get nostalgic for it sometimes, when I am working in the sloppy mess I am currently assigned to.

aslakhellesoy• 9 years ago

You and I have very different opinions on the purpose of TDD. You're presuming it's a design technique - many do. For me, TDD is all about validating a design in a way that gives me faster and better feedback than if I were just coding. I design the code before I write the first test. In fact, my test is derived from the design.

First I sketch a rough implementation design on a napkin or whiteboard. I don't worry about making it perfect, just good enough to create an initial mental model, and perhaps discuss it with someone.

Then, I write a test to express how I would like to interact with a small area of an implementation of this design, typically by calling a function or method and expressing a desired outcome.

I use the feedback from the test to drive out some simple code that resembles the design I sketched. If at any point this becomes hard, I take that as a clue that my napkin design can be improved, so I go back and tweak it.

Then I start over again. This is a quick cycle, typically 10 minutes or so. I get constant feedback on my design as well as my implementation.

I don't design code with TDD. I design code exactly the same way people who don't to TDD do it. Through intuition and experience. This is a skill, not a process. I only write tests to validate my design (not my implementation). Of course, because they are tests, they automatically validate my code as well, but that is not why I am doing it. If I only cared about testing, I might as well write them last.

More often than not my designs are imperfect, but by doing TDD I always improve them significantly, with relatively little time and effort.

It's taken me 15 years to get decent at it, and I'm still learning new techniques and abandoning others. There are many tricks to be learned. I usually only TDD when I care about the design. Quite often I don't, and then I just hack. I'm simply making a choice between going very fast now or going reasonably fast in a year. I haven't found a way to do both yet.

willvarfar5• 9 years ago

No article about TDD, particularly one that shouts out to the respected Ron Jeffries http://ronjeffries.com/, is complete without mentioning the TDD Sudoku Fiasco :)

Ravi has a nice summary: http://ravimohan.blogspot.se/2007/04/learning-from-sudoku-so...

Peter Norvig's old-fashioned approach is excellent counterbalance: http://norvig.com/sudoku.html

Cephlin• 9 years ago

Uncle Bob always has some clever things to say on TDD too: http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Ar...

and: http://blog.cleancoder.com/uncle-bob/2016/11/10/TDD-Doesnt-w...

hota_mazi• 9 years ago

I don't find most of the Uncle Bob writes to be clever, and especially when he writes about TDD.

He's just too dogmatic to be credible to anyone working in the industry (and make no mistake, Uncle Bob knows absolutely nothing of the software industry in the 21st century).

His writings are only here to promote himself, his books and his consultancy. That's it.

nikkettt• 9 years ago

Playing devil's advocate here: I'd say that algorithm design (Which is what a sudoku solver is) is a bad fit for TDD.

However, I'd argue that most problems in commercial coding are of a more engineering/architectural type of nature. Here, outside-in TDD has it's place.

Outside-in TDD can help you tackle problems that seem enormous, and slowly but steadily break them into smaller components.

willvarfar5• 9 years ago

I find TDD useless as a way of poking at problems I don't actually know how to solve (as Jeffries found with Sudoku), in the way and slowing down when writing large new systems, and excellent when bug-fixing maintenance. Test Driven Debugging!

ajross• 9 years ago

To be fair (and I'm no TDD fan personally), that mess wasn't really the fault of TDD at all. It was that Jeffries was learning how to write a Sudoku solver while he was writing his tests. If he started from Norvig's level of understanding, he surely could have written tests for an equivalently elegant solver quickly and simply.

Learning how to solve a problem by iterative coding (and throwing away the intermediate solutions) is a time-honored tradition that works very well. TDD may be an imperfect vehicle for doing that, but it doesn't really change the calculus.

willvarfar5• 9 years ago

The whole thing at the time was 'test driven design' - the idea that by writing tests, you could iterate your way to algorithms that solve problems you couldn't solve by critical up-front thinking.

Test Driven Design fizzled and quietly died just after the Sudoku Fiasco ;)

krmboya2• 9 years ago

Well, to me it seems that if you stretch the idea of separation of concerns, you should separate the process finding out what you should do, from the process of how you should do it right.

mjw10072• 9 years ago

The 'Fiasco' is a bit of an unfair comparison, because Jeffries is deliberately providing a 'stream of consciousness' writeup while Norvig's is a cleaned-up version with false starts removed.

(You can tell Norvig's code worked differently at one point by looking at the return value of assign(), for example.)

willvarfar5• 9 years ago

I would be staggered if Norvig's approach ever wasn't constraint propagation and backtracking.

Solving Sudoku is blindingly obvious even to mere mortals with even a iota of exposure to computer science and algorithms.

plinkplonk• 9 years ago

that 3 line post is the most popular blog post I ever wrote.

I got a lot of nasty mail from agile consultants, but it was worth it, heh!

Which reminds me, I haven't blogged in years.

One day I just stopped.

Perhaps it is time to restart.

mdpopescu2• 9 years ago

TLDR: TDD done badly doesn't work well.

falcolas4• 9 years ago

I'd say a better summary is that TDD won't transform OK programmers into great programmers.

paupino_masano• 9 years ago

I think it all depends on the context of what you're writing. For example, we use TDD when making additions and modifications to a tax engine. For this use case it's incredibly useful as the relative inputs and outputs are both predictable as well as repeatable.

norswap• 9 years ago

TDD never worked for me, I believe because of the nature of my work: research code, very explorative in nature. I do not now in advance how the interface will turn up, so it's hard to anticipate the interface in my tests (or it leads to a lot of wasted).

Nowadays I mostly test with "redundant random generation testing": generate random but coherent input, run logic, then... Either I can reverse the logic, and I do that and verify that I get back the original input. Or I can't and then I simply write a second implementation (as simple as possible, usually extremely inefficient). This finds bugs that classical unit and integration testing would never find.

neuromantik80862• 9 years ago

My former lab tried to use TDD. I've come to the impression that it's not the right approach for science / prototyping and just bogs you down. I don't think that science should eschew testing completely- I just think that something like your "redundant random generation testing" is more in line with what needs to go on. The trickier issue is changing your lab culture so that it actually understands the need to run tests of some kind consistently / with discipline.

daxfohl3• 9 years ago

This is funny, because as a consultant, I think to myself "TDD really doesn't work for me, because I've got so many 3rd-party dependencies that I have to mock out in my tests (which often makes unit tests seem more like a test of your mocks than of your actual application); TDD must really be best for researchy things where they don't have to deal with those problems".

ryanmarsh• 9 years ago

My day job is teaching TDD.

Just like other agile rhetoric I've found the benefits are not what the proponents advertise.

I teach it through pairing and here's what I find.

TDD provides two things.

1. Focus

Focus is something I find most programmers struggle with. When we're starting some work and I ask, "ok what are we doing here" and then say "ok let's start with a test" it is a focusing activity that brings clarity to the cluttered mind of the developer neck deep in complexity. I find my pairing partners write much less code, and much better code (even without good refactoring skills) when they write a test first. Few people naturally poses this kind of focus.

2. "Done"

This one caught me by surprise. My students often tell me they like TDD because when they're done programming they are actually done. They don't need to go and begin writing tests now that the code works. They like the feeling of not having additional chores after the real task is complete.

atonse2• 9 years ago

Regarding Focus, I have to agree mostly that pairing is amazing for focus. I've found that I never lose focus when I pair. And we almost always come up with better solutions when we think out loud.

Regarding being done, often this works for more cut and dry elements, which are increasingly more like boilerplate. But this doesn't hold up for what I nowadays spend most to my time on, which is UX and the experience of using the application.

lgunsch6• 9 years ago

I would agree with those two statements. They are even mentioned by Kent Beck, who created the technique in the first place, in his book Test Driven Development: By Example.

He spends a whole bunch of time hammering home the point that TDD is to help you manage complex problems and focus. He even mentions that if you think you can just power through the code and write it correctly in one swoop, then just do it. Skip TDD - it's not helping you then.

There are also other techniques he talks about regarding focus. For example, leaving a failing test as your last "bookmark" to where you left off for when you come back the next day. That allows you to jump right into where you left off, no ramp-up time at all.

wolco3• 9 years ago

TDD is designed for developers with advanced refactoring skills. By the time you reach that level you stop needing the organization ttd provides.

pif2• 9 years ago

A.k.a: no methodology will turn a coding monkey into a great developer. What a surprise :-)

johansch• 9 years ago

This (implied or not) seems to be the premise of many of these fads.

On the flipside: I think TDD is great for people who love writing code more than they love getting results. They get to write twice as much code!

im_down_w_otp• 9 years ago

PBT-centric TDD has worked very well for us.

emperorcezar• 9 years ago

Gonna throw the baby out with the bathwater because bad programmers write bad tests.

briandear3• 9 years ago

I disagree with the assertion that TDD takes more time. TDD takes less time if you factor in the reduction of errors TDD helps prevent.

This article should be renamed, “TDD doesn’t work if you don’t do it right.”

This article seems to argue for Big Design Up Front. Ok, if you do that, then why not write the tests for those designs after you make the design – then the code you write confirms to the design.

I don’t think anyone advocates that writing tests is the same as the design process. Tests are the result of design not the other way around. The gray area is not design up front – but how much design up front.

ericgunnerson9• 9 years ago

Original author here.

I get your point, but it's not really about not doing TDD right. It's about TDD evangelists - and I used to be one of those - advocating that people should use TDD despite those people not having the skills to do TDD "right". And my experience is that not only is doing TDD without those skills not a fun experience, the resulting code is worse than if you let those same developers write the code the way they are used to, and maybe spend some teaching time on refactoring because it's a more basic skill.

agentultra5• 9 years ago

Maybe the title should be: TDD did not live up to my expectations?

I too, like the author, have been practicing TDD for > 10 years. Test, implement, refactor, test... that's the cycle. If you follow that workflow I've never seen it do anything to a code base other than improve it. If you fail on the refactor step, as the author mentions, you're not getting the full benefit of TDD and may, in fact, be shooting yourself in the foot.

I've read studies that have demonstrated that whether you test first or last doesn't really have a huge impact on productivity.

However it does seem to have an impact on design. Testing first forces you to think about your desired outcomes and design your implementation towards them. If you think clearly about your problem, invariants, and APIs then you will guide yourself towards a decent system.

The only failing I've seen with TDD is that all too often we use it as a specification... and a test suite is woefully incomplete as a specification language. A sound type system, static analysis, or at the very least, property-based testing fill gaps here.

But for me, TDD, is just the state of the art. I've yet to see someone suggest a better process or practice that alleviates their concerns with TDD.

eropple17• 9 years ago

Testing first forces you to think about your desired outcomes and design your implementation towards them. If you think clearly about your problem, invariants, and APIs then you will guide yourself towards a decent system.

The way I put it: "if I don't know the domain and range of my function, I shouldn't be writing code yet, I should be investigating the problem."

TDD is for unit tests, and unit tests best test functional, stateless code--the functional, central logic of your application is what you should be specifying and writing unit tests for, not all the imperative stuff wrapping it for IO and failure catching and the like (Gary Bernhardt[1] calls it scar tissue).

[1] https://www.destroyallsoftware.com/talks/boundaries

tieTYT4• 9 years ago

TDD is for unit tests

Never heard anyone say this. Kent Beck has said the opposite on podcasts.

Retra2• 9 years ago

If you don't know the domain/range of your function, and you are forced to write tests in advance, then you will end up specifying a domain/range. The worry here is that you pick a domain/range that is really inefficient, and you write 'bad' code to support it, and you can't refactor it out without more overhead later.

Now, this is a minor issue. It's probably more worth it to build inefficient interfaces now and try to fix them later than to never build anything because you don't know what the optimal design is. I can't say if TTD gives a real advantage there, but when designing-while-coding-with-no-tests, you end up playing with the interfaces, changing them regularly, and learning something about why they are the way they are. Which is possibly a better process when you don't have any relevant design experience? I really don't know...

gurkendoktor• 9 years ago

I've yet to see someone suggest a better process or practice that alleviates their concerns with TDD.

I think that's part of the point. If you want to follow a process like clockwork, test-implement-refactor-test, then TDD might be the best we have.

But what if not having any process is better than even the best formalised process? That's certainly my personal experience: my haphazard, process-free way of hacking delivers solid results very fast.

HeroOfAges• 9 years ago

"If you think clearly about your problem, invariants, and APIs then you will guide yourself towards a decent system."

This is the most beneficial part of TDD to me. Most devs will deny this, but their biggest issue with TDD is not wanting to take the time to think clearly about a problem. To me that seems a bit sloppy and lazy. We're supposed to be professionals. From some of the comments I've read, it also seems that devs are trying to "test drive" or write unit tests for the wrong things. As I've gained experience as a software developer, I actually look for ways to write less code. The most effective way for me to do that, is to actually think about the problem before I write a single line of code. If I have a clear idea of what it is I'm trying to build, it's very easy for me to write a test first. If I can't identify a way to write a failing test, it's an indication to me that I really don't understand the problem well enough to deliver a dependable solution.

dwaltrip• 9 years ago

Do you use TDD on prototypes? Or other projects where the design is highly likely to change or be discarded?

danthemanvsqz4• 9 years ago

I don't use them on prototypes because I will throw away that code. But IMHO TDD is at it's best when your design is highly likely to change. The only protection you have against a moving target is your test suite. The requirements or our understanding of the requirements change so we change the code. In large code bases we can only be certain that the code change doesn't break anything if we have good tests. TDD is the only realistic approach to achieve 100% test coverage. You can certainly write good tests to cover your code at 100% but I've never seen it done by anyone consistently without TDD.

agentultra5• 9 years ago

Do you use TDD on prototypes?

Yes.

Or other projects where the design is highly likely to change or be discarded?

I don't often just start writing code without thinking about the design of the system or module I'm working on. Unless I'm writing a one-off shell script or some simple elisp glue code... I write the tests first.

draw_down3• 9 years ago

Maybe the title should be: TDD did not live up to my expectations?

That is the title. If you are arguing that explicitly specifying "my expectations" would significantly alter its meaning, I disagree. Otherwise, whose expectations were we to assume TDD did not meet?

dragonwriter3• 9 years ago

Otherwise, whose expectations were we to assume TDD did not meet?

Without qualification, I would expect those of the people choosing to adopt TDD generally.

nickpsecurity8• 9 years ago

"But for me, TDD, is just the state of the art. I've yet to see someone suggest a better process or practice that alleviates their concerns with TDD."

Design by Contract specifying key properties at interfaces with tests for stuff not easy to specify was state of the art in the 90's. In the 2000's, there's tools to automatically generate tests from such properties or apply formal proofs to code if it's simple enough. I don't see TDD as either strongest method or state of the art. DbC, assertion/property-driven testing, some fuzzing, and proving /model-checking for most important components collectively seem state-of-the-art for realistic software. Most of which is just automated versions of manual methods invented in the 50's-60's. Most being 60's with fuzzing going back to 50's.

One from later time I like since it consistently got low defect rate was Cleanroom. Here's a good explanation of it.

http://infohost.nmt.edu/~al/cseet-paper.html

agentultra5• 9 years ago

Hey nickpsecurity! :)

I don't see TDD as either strongest method or state of the art.

It's not the strongest method. But as far as the SWEBOK[0] is concerned it is state of the art.

The most effective teams I've worked with layer their testing strategies and use multiple approaches to verification depending on the needs of the project. I love quickcheck. I even pull out formal methods when the problem domain demands it or I need to check my thinking.

On the scale of "sketch on a napkin" to "verified and signed-off-by-master-engineer blueprint" I'd say a unit test suite, as far as it is a specification, is somewhere between napkin and the middle. If you use a soundly typed language AND a unit test suite using property-based assertions you're somewhere in the middle; building houses.

However I do see it as a warning sign if a team actively avoids TDD and tries to ship the first thing that works. If I was an actuary that project would represent a high level of risk and I'd probably raise their insurance rates to match that risk depending on the work they're trying to do.

colomon• 9 years ago

It always startles me when people assume that one programming technique either works for every type of programming or doesn't work for every type.

Working on Perl 6 compilers, an extensive set of tests was our best friend. It was (probably still is, I haven't had time to help the last few years) utterly routine to write tests first and then write the code to make them work. It was a perfect way of working on it.

On the other hand, one of my personal projects in Perl 6 is abc2ly. It has lots of low level unit tests, great. But almost everything really interesting the program does is really hard to test programmatically. How would I write tests to make sure the sheet music PDF generated has all the correct notes and looks nice? That problem is significantly harder than generating the sheet music in the first place!

maxxxxx2• 9 years ago

I also don't understand why people tend to elevate a technique that's very useful for some cases to a religion that needs to be followed always.

sqeaky3• 9 years ago

People have a constrained view. They see their own problems and have seen the "old" way do nothing but fail and the "new" way do nothing but succeed. What other reaction would you expect?

If they actively researched and looked beyond their personal experience then dramatic 0% to 100% Success rates would turn into more reasonable assessments.

I think my view on TDD is more reasonable than most of the zealots, but I still like mant of the ideas of TDD a great deal. I don't think it much matters if the tests come before or after the code as long as they come early enough to save time and effort. This means that specification of some kind is required, without specification you can't do TDD. Once you have tests and some code, you can add more test to increase confidence and with confidence you can aggressively refactor.

Sometimes its enough to write a minimal viable product and then write tests just so that refactoring for version 2 can be done reliably. I am doing something like this now for some C++ build system stuff... That sounds odd saying it loud, but yes I have cmake modules complex to need tests so I can be confident in refactoring them. But I didn't write any tests until the minimal viable version sort of work enough to have bugs filed against it. Now TDD on ethat project seems like great idea, when I didn't use any tests in the beginning (Partly because we couldn't specify what we wanted).

comstock• 9 years ago

It's interesting to me that programming is becoming a fundamental part of many (maybe most) things humans do. And yet we treat it as if there was one single correct way of programming and all other ways are wrong.

I feel like it's much more akin to human language. Though the language primatives might be the same, it's used differently in different contexts are appropriate.

In formal, legal speech, you might want to be explicit.

In informal, everyday speech, not so much.

Similar analogs exist in programming. 10 time script to reformat data for one time use, careful documentation, tests etc. not really required.

Aircraft flight control system, very different...

But then why is it that so many programmers seem to focus on "the one true way" (TDD, agile etc). Beats me.

dtech3• 9 years ago

I think TDD works great if you have a very clearly designed input or interface. A programming language falls under this category: here's a piece of code, make sure it compiles and returns the correct output is a perfect test. And one which you can defined beforehand and is achievable to write as a test.

However, programmers are often not in such a luxurious position. Business requirements are unclear, it is unclear what the solution even should look like, and the requirements will change over time and are changed based on the software's progress. In this case TDD only slows you down. It's also why short iteration times (i.e. agile) seem work relatively well in software development.

s73ver6• 9 years ago

If the requirements are unclear, then why are you writing code? Why aren't you having conversations with people to clear up those requirements?

lgunsch6• 9 years ago

It's exactly the opposite. TDD was a put forward as a solution to unclear, changing business requirements. It allows you to adjust course very quickly when the business realizes its requirements were off and new set of requirements are needed.

Robert Martin has even mentioned that it's a waste of time if you have a full 100% specification available to you, or when you already know what the final solution is and simply need to implement it.

slaymaker1907• 9 years ago

Manual testing should be avoided when possible, but sometimes it is absolutely necessary.

dcherman• 9 years ago

I've also never found TDD to really be very beneficial except for all but the most trivial utility libraries.

Most of the time, I have an idea of where I want to go, but not necessarily exactly what my interface will look like. Writing tests beforehand seems to never work our since nearly always, then will be some requirement or change that I decide to make that'd necessitate re-writing the test anyway, so why write it to begin with?

The extent of my tests beforehand these days (if I write any before code) are generally in the form of (in jasmine.js terms)

it('should behave this particular way', function() { fail(); });

Basically serving as a glorified checklist of thoughts I had beforehand, but that's no more beneficial to me than just whiteboarding it or a piece of paper.

That said, all of my projects eventually contain unit tests and if necessary integration tests, I just never try to write them beforehand.

Klathmon• 9 years ago

That's exactly how I've always done it, and it works beautifully for me.

Put "test stubs" out there that define what I'm testing in "human" terms, leave the stub either skipped or failing.

I've also found that if I wait a day or 2 after writing the implementation to write the tests, they catch much more.

If you write the code to match the tests, or you write the tests right after the code the chance that both the test and the code are wrong is much higher in my experience than if you wait a bit and come back to write the tests with fresh eyes.

eropple17• 9 years ago

necessitate re-writing the test anyway, so why write it to begin with

Because now you have an unambiguous record of the conscious decision to change your interface, because the test demonstrates the correct change of that interface.

I don't write tests first for everything I do, but I try very hard to when I'm writing code that other people may read for this exact reason. Otherwise they have to divine my intent through less significant means.

moron4hire5• 9 years ago

the test demonstrates the correct change of that interface.

No, they don't. Tests never prove correctness. They prove that assumptions are met. Whether or not those assumptions are correct is unprovable.

The problem is, there are changes to interface that could make the entire approach of the existing tests completely meaningless. If all you're doing is changing the name of a method, that can be practically automated away in most cases. But if you're changing fundamental behavior, like "we no longer add up a bunch of numbers and show them to the user here, now we print out a bunch of labels", then your leftover, failing tests are completely useless.

I've seen far too many cases in-the-wild where people either just deleted those tests, or faked-it-till-they-maked-it to force the tests to pass, without any thought putting into whether or not the tests prove anything important.

StevePerkins2• 9 years ago

Any programming language suitable for business application development is going to have static analysis tools that can reveal your percentage of test coverage.

As long as 95% (or whatever) of your logical branches are covered by tests, I don't really care whether you wrote the tests beforehand or after the fact.

However, TDD being hard is not a justification for not writing the test coverage at some point in the dev cycle. Too many developers, and managers, make that fallacy leap.

eropple17• 9 years ago

As long as 95% (or whatever) of your logical branches are covered by tests, I don't really care whether you wrote the tests beforehand or after the fact.

Do you care that those tests reflect the business goal or just the implementation? 'Cause TDD is way, way more likely to do the former than test-last development.

StevePerkins2• 9 years ago

What are you talking about? TDD generally deals with unit testing. Which by definition is more fine-grained than end-to-end integration tests against non-mock dependencies.

All of which is unrelated to UAT. Where you show the alpha to the business, and it's only after seeing it live for the first time that they start to get on the same page about what their business goals were to begin with.

jacques_chester3• 9 years ago

that can reveal your percentage of test coverage.

Many folk only try line coverage, which loses indicative value as you approach 100%.

pcarolan• 9 years ago

Defining the interface before you write the code is the major advantage of test-driven development and what it added to that way of thinking was very valuable especially to novices. It also makes your code more modular and reusable. Writing code as if other people were going to use it is something we don't talk about enough.

brango• 9 years ago

I found it just flew in the face of iteration. I get something simple working, then iterate a few times, adding complexity. If you have to iterate your tests as well, you're just walking in treacle.

Either that or you end up with a load of stuff in your interface that you thought you'd need, but when you actually got to it you either didn't, or it wasn't important to implement at the outset.

dccoolgai• 9 years ago

Contract-driven development is the best model for building stable and reusable systems at scale. The flaw in TDD is that it tries to make the tests be the contract instead of supporting the contract.

nostrademons7• 9 years ago

TDD failed for economic reasons, not engineering ones.

If you look at who were the early TDD proponents, virtually all of them were consultants who were called in to fix failing enterprise projects. When you're in this situation, the requirements are known. You have a single client, so you can largely do what the contract says you'll deliver and expect to get paid, and the previous failing team has already unearthed many of the "hidden" requirements that management didn't consider. So you've got a solid spec, which you can translate into tests, which you can use to write loosely-coupled, testable code.

This is not how most of the money is made in the software industry.

Software, as an industry, generally profits the most when it can identify an existing need that is currently solved without computers, and then make it 10x+ more efficient by applying computers. In this situation, the software doesn't need to be bug-free, it doesn't need to do everything, it just needs to work better than a human can. The requirements are usually ambiguous: you're sacrificing some portion of the capability of a human in exchange for making the important part orders of magnitude cheaper, and it's crucial to find out what the important part is and what you can sacrifice. And time-to-market is critical: you might get a million-times speedup over a human doing the job, but the next company that comes along will be lucky to get 50% on you, so they face much more of an adoption battle.

Under these conditions, TDD just slows you down. You don't even know what the requirements are, and a large portion of why you're building the product is to find out what they are. Slow down the initial MVP by a factor of 2 and somebody will beat you to it.

And so economically, the only companies to survive are those that have built a steaming hunk of shit, and that's why consultants like the inventors of TDD have a business model. They can make some money cleaning up the messes in certain business sectors where reliability is important, but most companies would rather keep their steaming piles of shit and hire developers to maintain them.

Interestingly, if you read Carlota Perez, she posits that the adoption of any new core technology is divided into two phases: the "installation" phase, where the technology spreads rapidly throughout society and replaces existing means of production, and the "deployment" phase, where the technology has already been adapted by everyone and the focus is on making it maximally useful for customers, with a war or financial crisis in-between. In the installation phase, Worse is Better [1] rules, time-to-market is crucial, financial capital dominates production capital, and successive waves of new businesses are overcome by startups. In the deployment phase, regulations are adopted, labor organizes, production capital reigns over financial capital, safety standards win over time-to-market, and few new businesses can enter the market. It's very likely that when software enters the deployment phase, we'll see a lot more interest in "forgotten" practices like security, TDD, provably-correct software, and basically anything that increases reliability & security at the expense of time to market.

[1] https://dreamsongs.com/RiseOfWorseIsBetter.html

taeric9• 9 years ago

No. TDD failed for engineering reasons in addition to economic ones.

The main failing of TDD is the assumption that you know all of the tests that you will need before you know your software. This is true in bridge building as much as it is in anything else. Until you fully know the domain of what you are building, you cannot possibly know all of the things you need to test for.

To that end, if TDD were focused around building things to break them and analyze them, it would be wise. However, in software it is often taught to build a wall of failing tests, and you can then use that as a sort of burn down chart for progress. Note that you don't learn about the software you are building from this burndown. Instead, you only get a progress report.

And obviously, this is all my opinion. I'm highly interested in exploring the ideas. And I'm highly likely to be wrong in my initial thoughts. :)

s73ver6• 9 years ago

I've never heard TDD being that you write all of your tests up front, before you've written any code. I've always heard it as: When you're writing a class/unit, you write a few tests for what that unit is going to do. You then make those tests pass. You add some more tests, make those pass, and so on and so on.

annabellish• 9 years ago

However, in software it is often taught to build a wall of failing tests

People teaching that are not teaching TDD. They may be letting the tests drive the development, but TDD specifically is _all_ about the second-to-second cycle of moving between test and code. If you write all the tests up front then refactoring is expensive and you've locked in your design way too early.

amirouche• 9 years ago

I don't do the TDD like a waterfall. I don't do upfront all the tests, there is a discussion between the code (what express the business need) and the tests that "wraps" it inside a safe zone (what ensures that the behavior is the one intended). As such, as the idea grow, both the code and the test grow at the same time. Look at [0] to have an idea of how the tests extend the safe zone along the code.

Also, I much prefer a lot of nice unit tests over a lot selenium tests (which takes a lot of time to run).

[0]https://github.com/charlesthk/python-resize-image/commits/ma...

enraged_camel• 9 years ago

Yes, precisely.

TDD works for experienced developers who know the problem domain well. It does NOT work for that new junior dev you hired straight out of college. They need to write functions and features first and see the spectacular ways in which those functions and features can fail (in a dev/test environment, hopefully), and then use that experience to switch over to TDD when they write a similar feature/function in their next project.

lliamander5• 9 years ago

It's worth noting that Kent Beck ("Father of TDD") himself said that TDD doesn't always make sense. For him, the important thing has always been having a tight feedback loop for determining if he was still on the right track.

For instance, when he was working on an unstructured log parser, there was no way TDD would work because the logging stream didn't have a pre-defined structure. Instead, he developed a process where he could quickly inject his parser into the logging stream, visually inspect the results, tweak, and then test again.

Others (Such as Martin Fowler and Uncle Bob) have also emphasized the value of automated unit testing integrated with a CI pipeline as a way of ensuring that you didn't break existing functionality.

As always, what's important is not the specific practice, but rather the engineering principles behind it. The key questions being:

* Am I on the right track?

* Did I break existing functionality?

* How quickly and frequently can I get answers to the above two questions?

yebyen3• 9 years ago

The main failing of TDD is the assumption that you know all of the tests that you will need before you know your software.

You know what makes this work for me (I am a TDD & BDD dev, and I don't think it's dead) is the fact that you can reorder commits. When I hit a case like this, where the correct code is easier to write than the correct test, I still test it.

I write the test after, then I reorder the commits once the test passes, and make sure it fails predictably in the way you were expecting it to fail. Sometimes you find your test doesn't fail correctly with the codebase you had before the feature was implemented, and then you amend the commit and use rebase or cherry-pick.

Adding BDD to the mix helps a lot too. Sometimes you can write the whole test up-front! Sometimes you can write pseudocode for the test, but you don't have enough information about the details of the implementation to write what you'd call a complete test before the feature is born. Usually you can at least get a vague, english-language description of what the feature is supposed to do.

Then you have, at least, a foundation for your test (which can ultimately be upgraded to an executable proof/regression test), and you have a way to measure how far from the vague, usually simple, plain-english description of the feature you've had to go in order to produce "correctly behaving" code. (And you can amend the behavioral spec to correctly explain the edge cases.)

I am in the habit of telling my team members with less TDD and BDD experience, who are just trying to get the hang of building up a codebase with strong regression tests, that they should always try to write a Cucumber Scenario before they wrote the feature, even if they don't write step definitions until (sometimes a great while) after the feature is done.

I agree that the burn-down chart is not the end goal of TDD, and you should not optimize your process simply around making sure you have a progress chart and a great estimate up-front. Complete coverage of the codebase is more important! And surely there are other things even more important than that.

dang4• 9 years ago

the assumption that you know all of the tests that you will need before you know your software

I'm not a TDDer but must object on their behalf: not only is that not what they said, it couldn't be further from it! What they taught was to work in short iterations and work out a bit of requirements, design, and implementation in each one. If you needed knowledge you didn't have yet, they would advise you to make each cycle shorter until you did. Sometimes they'd take this to absurdity, breaking even simple features into design-test-implement cycles so microscopic that you would feel bored like a kid in class who can already see the next dozen steps and has to sit there waiting for the teacher to catch up.

The TDD approach was at the extreme tip of trying to get away from waterfall methods, so it would be quite some irony if it reduced back to that.

Edit: looks like I misread what taeric meant! But as McLuhan said, 'you don't like those ideas, i got others'...

In my experience there were two problems with TDD. One is that the micro-iterative approach amounted to a random walk in which features agglutinated into a software blob without any organizing design. Of course that's what most software development does anyway. But if you remember what Fred Brooks et. al. taught about having a coherent design vision for software that can organize a codebase at a higher level, the way iron filings are ordered by a magnetic field, that is a key anti-complexity vector which the TDD/XP/agile projects I saw all lacked. (Original XP had a notion of 'metaphor' that pointed vaguely in this direction but no one knew what it meant so it had no effect.) The lesson was that a coherent design vision doesn't evolve out of bit pieces, and there is an important place for the kind of thinking that got dismissed as 'top-down'. (Edit: by far the deepest work on integrating design coherence into TDD/XP approaches was Eric Evans' stuff on domain models and ubiquitous language. Eric is my friend but I knew he had the best stuff on this before that :)) (Edit 2: Eric points out that the people who created TDD were software design experts for whom coherent design was as natural as breathing air. The admonition against too much design thinking in TDD was intended for people like themselves, for whom the opposite mistake was never a risk, and didn't have unintended consequences until later.)

The other problem was that practices that started out as interesting experiments ossified into dogma so damn quickly that people started acting like they'd cracked the code of how to build software. A soft zealotry emerged that was deeply out of sync with the playful, adaptive spirit that good software work needs. This was unintentional but happened anyway, and there's a power law in how much creativity it kills: each generation that learns the Process is an order of magnitude less able to think for itself within it, and so must break free. I don't think the creators of the approach were any more at fault for this than the rest of us would have been in their shoes. The lesson is that this ossification is inevitable, even if you know all about the danger and are firmly resolved to avoid it. If there is any real breakthrough to be had at the 'how to build software' level, it is probably discovering some kind of antifreeze to put in there from the beginning to make sure this doesn't happen. Maybe there's a way to interrupt the brain and social circuitry that produce it. Failing that, I think that each project or maybe (maybe!) organization should hash out its own process from first principles and the prior experience of team members. That's ad hoc and involves a lot of repeating past mistakes for oneself but at least it isn't idiotifying. It's how I like to work, anyhow, and IMO that's what all software processes reduce to.

api• 9 years ago

I guess another way to put it is that TDD is an attempt to do old school "waterfall" in code form.

Way back before anyone really understand how software engineering should be done, people would begin a software product by attempting to pre-specify ahead of time every nuance of the system. They'd write these massive books of requirements. Then they'd get to work coding to these requirements.

This rarely worked out well and usually resulted in huge amounts of wasted effort. When you get coding you realize the spec is either wrong or there's a much, much better way to do it. Do you do it the bad way to stick to the spec or do you deviate from the spec?

The other problem with this approach is that the requirements are often as hard to write as the code and contain as much information. Why not just write the code?

TDD is just "the spec" written in code instead of as a massive design document. Attempting to achieve 100% test coverage often means writing a test set that is a kind of negative image of the code to be written and is equal in complexity. As such the tests often end up containing bugs, which is the same problem as the classical "when we got going we found that the spec was wrong." Do you code to the bugs in the tests?

This is not to say tests should be skipped. Automated tests are great. I just think the 100% test coverage TDD dogma is oversold and doesn't really work well in practice. Test where you can. Test where you must. Keep going.

Of course I am not a fan of "methodologies" in general. I see them as attempts to replace thinking with rote formula. That categorically does not work outside domains that are purely deterministic in nature, and those can be fully automated so humans aren't needed there at all.

There is no formula, or alternately the formula is general intelligence continuously applied.

Edit:

The same evolution has happened in business. Nobody writes a "business plan" anymore. As soon as you get into business you have to toss the plan so why waste your time. Planning is a false god.

danthemanvsqz4• 9 years ago

In TDD you don't build a wall of tests, you build your tests as you build your code. Test a little, code a little, refactor, repeat.

kybernetikos• 9 years ago

The main failing of TDD is the assumption that you know all of the tests that you will need before you know your software.

I don't think this is true. TDD is also taught as a way of exploring a space and a codebase.

And there is no assumption that the tests created during TDD are the only tests you will need. They're the tests needed to drive out the desired behaviour. You'll also need tests to check edge cases, tests that operate at a higher level, tests that integrate different systems, nonfunctional tests, etc....

In a lot of ways they are a discovered, executable spec.

To that end, if TDD were focused around building things to break them and analyze them, it would be wise. However, in software it is often taught to build a wall of failing tests, and you can then use that as a sort of burn down chart for progress.

I've never come across TDD taught that way. Hard core TDD as I know it is RED, GREEN, REFACTOR. You never want more than one failing test, and you don't generalise until you've triangulated based on creating tests that force you to.

I don't personally use TDD on all my projects because often it feels fussy and constraining when you are in exploration mode, but I also don't think it failed. I know people who find it valuable even for exploration. I'm also a big fan of using it for certain kinds of things - e.g. building a collection class.

ngoede• 9 years ago

That is not at all the assumption. The assumption is that you have some idea what you want a particular piece of code, method, or class to do and you write a test for a small piece of that and then after it passes you do that again.

At no point does TDD suggest you should know all the tests you want upfront. In fact I would expect if you know that then you don't need TDD. TDD is about learning what tests you need and what you want the object or code to look like one small piece at a time.

Udik• 9 years ago

Aren't you two saying the same thing? TDD works when the requirements are well defined upfront, which in the case of fixing existing system is provided by the system itself. But writing new programs is exploratory in nature: you don't know the exact requirements or shape your software will take, and TDD shifts a lot of precious money, time and attention from the what to the how. Which to me, I agree with you, is an engineering issue before being an economic one.

th4dv• 9 years ago

The main failing of TDD is the assumption that you know all of the tests that you will need before you know your software

One of the main failings of TDD is that developers think they need to know all of the tests up front.

ajeet_dhaliwal• 9 years ago

I think the failures are due to a combination of engineering, economic and human reasons.

TDD is counter intuitive to how most people think and work. They think of the features first, implement them and then once it's working want to have tests to ensure it stays working, especially with continuous delivery, testing is mostly about checking for regression as high frequency iterations are done.

Even if things starts out ok, often at some point, some person in the team breaks the flow. You have to be quite rigid about procedure and in my experience most teams don't have the discipline for it. This is especially true when there are business pressures in some companies that put pressure on the development team. We've all experience instances where a program manager or producer asks for estimations and an inexperience developer only considers the coding time. To be honest, unless you're working at one of the top tech firms where everyone is interested in solid engineering and there's adequate revenue to enable this, I still find even basic automated testing in general is still a struggle to have in some companies. The reason for this is because the increased development cost is difficult to measure and so it's absorbed as a cost. They don't realize how much development is costing because they cannot compare it to the alternate reality where they did things a better way. Whereas feature issues are obvious to see for everyone.

bm2yogi• 9 years ago

"The main failing of TDD is the assumption that you know all of the tests that you will need before you know your software."

If that's what TDD is, then it can only fail. Fortunately, TDD does not require you to write all your tests up front (see "The Three Rules of TDD").

I spend a lot of my time interviewing people and talking with people about TDD. In the vast majority of cases, I find people who dislike TDD are often doing "Not TDD, but called TDD." If I were to write software that way, I too would consider that TDD did not live up to expectations.

hinkley6• 9 years ago

I have a colleague who is not a household name but still fairly widely known in the software process space and he has insisted to me multiple times, for more than ten years now, that this is a west coast thing. Other parts of the US are much less allergic to discipline in development.

nostrademons7• 9 years ago

I'd agree with this characterization. I started my career in Boston - actually, one of the first companies I interned at did high-assurance systems for avionics, financials, and medical devices.

However, look at the size of the West Coast tech industry vs. the size of tech firms in New England or the Midwest. That's what I mean by an economic argument. I got paid 5x more at Google than I did in Boston, and I was employee #45,000 or so, not even an early employee.

mixmastamyk• 9 years ago

Research and startups are on the west coast, government and finance on the east coast. Q.E.D.

jacques_chester3• 9 years ago

Other parts of the US are much less allergic to discipline in development.

I see TDD as a practice that requires a lot of discipline.

The TDD equivalent of crossing every t and dotting every i requires sustained attention and intention.

pif2• 9 years ago

Other parts of the world are, too :-)

nickpsecurity8• 9 years ago

That's a great write-up on the situation. There's one thing I'll counter:

"And so economically, the only companies to survive are those that have built a steaming hunk of shit,"

This is true in average case because most of these startups don't care about quality that much since they don't have to for reasons you describe. However, if they did, then they could at least document things, do limited amount of Design-by-Contract, and/or do assertion/property-based testing as they went along. They can also follow principles like cleanly separating modules, protocols that have an update feature, standardized formats for data, and so on that can make rewriting a lot easier later. Easier, not easy, as rewriting is also difficult. That's why I mentioned documentation and Design-by-Contract as they take very little time. Essentially just write down whatever was in your head at that moment.

Most of the time will still go to experimentation and debugging which... wait, styles like Design-by-Contract in safe languages knock out a lot of that debugging. Good docs do, too. Now, we've gotten to the point illustrated by methods like Cleanroom where the QA might cost a little extra, might cost the same, or might even save time/money due to less debugging of new or old code.

Retric• 9 years ago

Which is another way of saying TDD is somewhat usefull, if you start from a huge pile of code written by someone else.

When you think this might be going on, so if I do this it should work... then writing some tests will help decide if your assumptions or your code is wrong. Most importantly you are probably writing minimal code in those situations so the overhead of tests is minimized.

nostrademons7• 9 years ago

Or even just a clear spec from a customer who knows what they want.

The challenge in most of the software industry is that the customer does not know what they want, and oftentimes it isn't even clear who the customer is. TDD is great if you can define your problem well enough to write tests for it up-front. Most software problems with a decent economic return are not like that.

marcosdumay2• 9 years ago

TDD is useful if you start from a well defined specification. The better defined, the more useful it is, starting from a big negative utility when you don't know your problem.

jrs235• 9 years ago

P.S. If you click the [1] link above you will be taken to an imgur image making fun of Hacker News.

To read the real article you'll need to copy and paste the URL address in your browser. Looks like the site is reading the referrer and forwarding to mean things...

nostrademons7• 9 years ago

I updated the link to point to the DreamSongs original. Sigh, jwz. Ironically, DreamSongs is the personal site of the guy who actually wrote the essay, but it's way down in the Google results because everybody links to the jwz mirror.

LrnByTeach• 9 years ago

Software, as an industry, generally profits the most when it can identify an existing need that is currently solved without computers, and then make it 10x+ more efficient by applying computers.
In this situation, the software doesn't need to be bug-free, it doesn't need to do everything, it just needs to work better than a human can.

Well said, these statements underscores importance of FINDING the PROBLEMS/TASKS that are done by HUMANS/MANUAL that can be AUTOMATED with COMPUTERS that can yield 10X efficiency .

Here are few gems from the original article https://blogs.msdn.microsoft.com/ericgu/2017/06/22/notdd/

The ability to write and refactor code to a state with low coupling, well-separated concerns > TDD Skills

1/ Design on the fly is a learned skill. If you don’t have the refactoring skills to drive it, it is possible that the design you reach through TDD is going to be worse than if you spent 15 minutes doing up-front design.

2/ I think that’s a good summary of why many people have said, “TDD doesn’t work”; if you don’t have a design with low-coupling, you will end up with a bunch of tests that are expensive to maintain and may not guard against regression very well.

haskellandchill2• 9 years ago

TDD failed? The use case of unknown requirements is precisely what we solve everyday with TDD at Pivotal Labs, as consultants! It works, but I don't have time to outline our process right now.

IgorPartola• 9 years ago

Software, as an industry, generally profits the most when it can identify an existing need that is currently solved without computers, and then make it 10x+ more efficient by applying computers.

Which is exactly how testing should be done. If you have a piece of software that you test so frequently by hand that you could get actual ROI by automating the testing, awesome. If you don't, then what exactly are you getting out of all the automated testing of code that often never changes with tests that essentially assure you that 2 + 2 is still 4?

swift• 9 years ago

It's all a balance, but one thing to consider is that future maintenance or new development may require changes to that software. At that time, having good tests will help you avoid breaking things in subtle ways. The problem is that when you reach that point, nobody may remember enough about that code to write the tests, so it's preferable to have already written them.

If a piece of software is trivial or isn't core to your business, though, obviously this doesn't apply.

agentultra5• 9 years ago

You're assuming TDD has failed and are reaching for evidence to make your case.

From the SWEBOK [0]:

  5.1.5 Test-Driven Development

  [1, c1s16]

  Test-driven development (TDD) originated as one of the core XP (extreme programming) practices and consists of writing unit tests prior to writing the code to be tested (see Agile Methods in the Software Engineering Models and Method KA).
  In this way, TDD develops the test cases as a surrogate for a software requirements specification document rather than as an independent check that the software has correctly implemented the requirements.
  Rather than a testing strategy, TDD is a practice that requires software developers to define and maintain unit tests; it thus can also have a positive impact on elaborating user needs and software requirements specifications.

It really depends on many more factors than getting to market first. If we developed software in this way for fighter planes or search engines I think we wouldn't find them nearly as useful. Perhaps even dangerous.

In the absence of a more formal software specification or testing strategy TDD is the best way for a self-directed team of software developers to maintain that specification.

Beyond that it also has benefits for practitioners working in languages that lack a sound type system to catch domain errors for them at compile time. Coupled with property-based testing TDD can be extremely effective.

[0] http://swebokwiki.org/Chapter_4:_Software_Testing

kafkaesq• 9 years ago

TDD failed for economic reasons, not engineering ones.

And yet, engineering is inseparable from economics.

ericgunnerson9• 9 years ago

Author here...

I agree that time to market is really important, but when a company is searching for the product that will work, the most important thing that you can have is code that is easily refactored, which generally means low coupling.

TDD is one way to get there for some people, and it's not 2x the amount of time. My experience is that TDD takes a little bit longer (say 30%) than just writing the code, but my bug rate with TDD code (and I don't do TDD for all my code) is very small. Bugs are so damn expensive that 30% to not have them is a small investment, even if that were the only benefit you got.

zabil• 9 years ago

Well, there's time you save on testing.

TDD gives me quick feedback. Its faster to run unit tests vs deploying and testing the functionality. I'd say TDD adds very little or no overhead.

tieTYT4• 9 years ago

Software, as an industry, generally profits the most when it can identify an existing need that is currently solved without computers, and then make it 10x+ more efficient by applying computers. In this situation, the software doesn't need to be bug-free, it doesn't need to do everything, it just needs to work better than a human can.

Unfortunately, the project isn't "finished" after you achieve initial success. You have to maintain it for years after that. Without good tests, you get yourself into a state where one change breaks two things. You need teams of people manually checking it still works. It takes them an order of magnitude longer to check than it would take a computer. Your feedback loop that answers the question, "does it still work?" is in weeks instead of minutes.

You stop changing the bad code because it's too scary and dangerous. The bad code reduces the frequency at which you release new features. You slow to a crawl. The team of people testing gets expensive and eats into your profits. Some competitor eats your lunch.

In my experience, these problems occur earlier than you expect. Usually before you even attain success. I'm too lazy to comb over my app checking for bugs every time I develop a new feature. I get bored too easily to check that the same bug doesn't crop up over and over again. I'm also too impatient to wait for another person to do it. In these conditions, TDD speeds you up.

I've never worked on a manually tested project that avoided these problems. It usually happens around month 2 and gets even worse as time goes on.

Here's why I think TDD fails: The consultants say, "it's so easy! Just red-green-refactor!" No, it's extremely complex and difficult, actually. There's a ton of depth that nobody talks about because they're trying to get you to try it. The typical dev learns about "Just red-green-refactor" and fails. Now "TDD did not live up to expectations".

For example, did you know there's different styles of TDD? The author of this article doesn't seem to (I may be wrong, but he gives no indication). He's talking about Detroit style TDD (also known as classicist). This is the style Ron Jeffries, Uncle Bob, Martin Fowler, Kent Beck, etc. practice and advocate for. There's another style called London style (AKA mockist) that Gary Bernhardt, etc. practice. And then there's Discovery Testing from Justin Searls. There's probably others I haven't heard of yet.

They all have different pros and cons and a very common pitfall is to use a style in a way it's not really meant for. e.g., Using mockist to gain confidence your high level features work. Expecting classicist to help you drive out good design for your code.

To wrap this up, there's so much unknown unknowns about TDD it's usually premature to judge the technique. If you haven't tried all these styles, one might click with you. A lot of people are concluding they hate all sports when they've only tried baseball.

nickpsecurity8• 9 years ago

"Unfortunately, the project isn't "finished" after you achieve initial success."

It is if the goal was to sell the company and people bought it. After the success, the remaining problems are the buyer's while the money is going to the sellers. Is that a perverse incentive for quality or what? ;)

danthemanvsqz4• 9 years ago

So there is a tipping point when the technical debt you acquire from not testing catches up with you and cripples the project. I think this tipping point comes much faster than people realize. Most people have no idea how bad their tech debt is until it's too late. Then you see one failure after another while management tries to fix the train wreck. At this point any good Eng is going to bail in this market and you're stuck with the scrubs.

collyw2• 9 years ago

The crippling debt is caused by not refactoring, not lack of testing. Admittedly testing will make the refactoring easier, but thats not the root of the problem.

icebraining• 9 years ago

This is not how most of the money is made in the software industry.

Are you sure? I agree that the most profitable companies are not doing that, but at least from what I've seen in a few European markets, the number of developers writing custom software for one client (consulting or in-house) or maintaining stable applications absolutely dwarfs the number of developers writing new products.

I work on a consulting company that customizes a relatively little known open source platform (Odoo) and the number of small and micro companies doing the same over the world is staggering.

dredmorbius• 9 years ago

Props for mentioning Carlota Perez. I'm familiar with her Technological Revolutions and Financial Capital (which is quite good). Are there any other works you'd recommend?

http://www.worldcat.org/title/technological-revolutions-and-...

There've been a few HN submissions over the years:

https://hn.algolia.com/?query=carlota%20perez&sort=byPopular...

EpicEng• 9 years ago

This was always my issue with TDD. I never tried it, but I know that the way in which I have written software for more than a decade is "get a loose set of requirements, start digging, write some code, figure out what works and what doesn't, change things, repeat until done."

I never saw a way in which I could write a large number of tests up front.

spronkey3• 9 years ago

This is basically the workflow with TDD though, and if you're writing a large number of tests up front, you're certainly doing it wrong.

lza• 9 years ago

This!! x100, I am constantly working on features that are not even decided if they go into production. Using TDD for these would be a huge waste of time and energy. Once a feature is accepted I write tests to cover it... after it's already being used and getting feedback from users.

zorked• 9 years ago

And another generation of programmers learns that there is No Silver Bullet[1].

This will happen again and again.

[1] http://faculty.salisbury.edu/~xswang/Research/Papers/SERelat...

a_imho• 9 years ago

Indeed, as long as there are people caring enough to seek out ways to improve their product/craft, there will be an ample supply of silver bullet merchants to satisfy the demand. Predictably with discussions along the same fault lines too (works for me, hate being forced to use it, you are doing it wrong etc.)

alexandercrohde• 9 years ago

Tl, dr: When we treat unit tests as an ends in itself, this leads to writing clunky tests for clunky code. If an engineer doesn't understand modular, reusable code then that engineer can't won't be able to write code that can tested easily. Thus understanding design is a prerequisite to effective TDD.

AdmiralAsshat• 9 years ago

Stylistic critique of the article: Is it too much to ask that you enumerate your acronym at least once throughout the entire article? The acronym "TDD" appears 16 times throughout the article, and not once do we get "Test-driven development" spelled out.

I get that it's a technical blog, but "TDD" isn't exactly a household name. You can't utter it in the same breath as SSL or RSA and expect people to know what it means without context.

As a test (no pun intended), try reading the article with the premise that you have NO idea what "TDD" stands for. Can you reasonably infer it from the rest of the article?

briandear3• 9 years ago

What’s RSA?

nekitamo• 9 years ago

https://en.wikipedia.org/wiki/RSA_(cryptosystem)

marcosdumay2• 9 years ago

It's an encryption algorithm... And a proper name, not an acronym¹, detracting from the GP's point.

1 - Ok, it's technically an acronym, with a meaning different from the thing it names.

_Codemonkeyism• 9 years ago

I love unit tests, they give me a good vibe and find some kinds of bugs - mostly b/c I think differently about a problem.

TDD never worked for me, b/c the code goes through many refactorings until I'm happy and it always felt tedious refactoring the TDD tests.

buckbova• 9 years ago

Seems a little arrogant to say most developers don't know how to refactor or do it poorly. Maybe it's true. I really can't say one way or the other because what I see is most devs believe they don't have time to refactor.

sqeaky3• 9 years ago

Is the difference between inability and ability but not doing so great?

mparr4• 9 years ago

most devs believe they don't have time to refactor

tough to do something well if you don't spend time doing it

spdionis2• 9 years ago

If most devs don't have time to refactor, then most devs have not had much experience doing refactoring, thus most devs are bad at refactoring.

Sounds reasonable.

ericgunnerson9• 9 years ago

Original author here...

Let me ask you - and by "you", I mean everybody reading this - a question.

If you had poor design or refactoring skills, how would you know?

Let's just say you've finished working on some code that involved writing new code. How do you know whether it's well-designed?

Well, you start by using your own sense of what is good design. But all of us can only see the things that we already know about, which us thinking that the code has decent design is only a sign that it is up to our level of understanding. This is a fundamental part of how knowledge works.

Code review can give some additional design feedback, but 1) code reviewers generally don't have time to give in-depth design feedback and 2) "you should redesign this" is generally not well received (see previous point about everybody thinking they are good designers), and I both have to work with my teammates and their comments factor into the kind of review I get. So, code review is not a good way to improve design change, even assuming that you have people on your team who have useful design advice to pass on and you are in the kind of environment that lets you be thoughtful about design.

If you are in a team with decent designers and your team pairs, then you are in luck; you have a good chance to expand your design skills. Leverage this at every opportunity.

Finally, it is possible to spend time (almost always your free time) learning more about design, doing katas, going to code retreats, etc. This also works.

And I'm sorry if this sounds arrogant; I've tried to find other ways of saying it.

Ace172• 9 years ago

most devs believe they don't have time to refactor

Try asking them:

"if you had the time to do it 'well', what would you have done differently?"

(By the way, the same works for testing: "if you had the time to write all the tests you want, how would you test this code?")

You might be surprised.

sevensor• 9 years ago

TDD has worked well for me exactly once: porting a library from to Python to C. I had a very clear idea of what every function was supposed to do and I could write tests first. Due to the nature of the library I was able to write tests that generated lots of random inputs and check the properties of the outputs. This was a great experience --- it was very easy to change the internals without fear of breaking something. Ordinarily writing C is a bit of white-knuckle experience, but this made it quite pleasant.

perlgeek• 9 years ago

When reading the title, I had hoped for data. Like when Microsoft analyzed their own developer's data to find out if remote work impacted productivity or bug counts.

Instead, just another piece of anecdote. Sure, anecdotes from 15 years, still not what I hoped for.

Doesn't Microsoft have hundreds of dev teams, and can compare things like development speed and bug counts, and correlate with whether those teams practice TDD? I'd read that article immediately!

joeblau• 9 years ago

wolco3• 9 years ago

TDD could be the reason for the bad system design. If you are writing to pass a test if you do not refactor you end up with a mess. Why not write it properly as a first step and start adding the tests later in the process.

mattmanser• 9 years ago

That's exactly what he said in the article, but I love your delightful added knife twist of calling him bad.

dreamdu5t2• 9 years ago

TDD: For people who've never used a decent type system.

Writing a Solidity test to add two integers today really drove home the point.

eropple17• 9 years ago

The language I've been most effective with when using TDD is Scala.

dreamdu5t2• 9 years ago

That's great. In my experience, most TDD has looked like "We're going to need a function or class to do this, so let's write a test that calls all those methods first." Which is absolutely ridiculous when we could just be using languages that have concise semantics to describe what they actually do.

For example, the last HTTP API I wrote in Haskell has no tests. The proper request/response is ensured by the types alone. I've had multiple jobs where I spent weeks writing tests to do the equivalent thing with a nodejs API (the body should contain this, the headers should look like that, etc.)

elliotec• 9 years ago

Very relevant 3 year old DHH article: http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv...

didibus• 9 years ago

I remember an old Microsoft analysis where they measured empirically time to delivery and actual defects and found TDD to not reduce defects while increasing time to delivery. Can't find it anymore.

S_A_P• 9 years ago

One thing I've noticed. TDD takes longer. It just does. You can argue that you are racking up less technical debt in the long term but every consulting gig I've been on where TDD was the "directive" often deteriorated because the business does not want to factor in between 40 and 100% extra time to allow proper TDD coding. They want the same somewhat arbitrary and bonus driven deadlines that they always do, and in order to meet them, we usually end up tossing out TDD halfway through and reverting to just having skilled developers get the job done as quickly as possible.

THIS is the economic reality of TDD failing. A manager wanting to reduce quarterly spend so he gets his bonus doesnt care that TDD will cost him less over 5 years, he cares that he can get a project delivered on time and under budget...

s73ver6• 9 years ago

Maybe if that bonus was tied to the amount of critical bugs that came back within the next year or so

jldugger• 9 years ago

One thing I've noticed. TDD takes longer.

It's not just you, there's ample evidence[1][2] that TDD is a tradeoff between delivery time and quality. I think most experienced practitioners would agree this makes sense: when the schedule slips, you can cut testing but you can't cut implementation. Works at all beats trumps works in all cases.

In the TDD model, you make that decision up front, as well as the investment in tests. When the schedule slips in development, there's nowhere to cut but the most painful part, so you don't. The schedule slips.

To take a contrarian position, TDD fails because it doesn't allow management to revisit decisions as reality deviates from the plan N months ago. This seems like a surprisingly non-agile approach at the high level.

[1] https://pdfs.semanticscholar.org/4dcf/5e7eed29c6707a8e1a415c...

[2] https://www.infoq.com/news/2009/03/TDD-Improves-Quality

exabrial• 9 years ago

TDD takes discipline, planning, and creates stability; I think in the day and age of "rewrite it using the latest framework" it just doesn't coincide with the insatiable thirst developers to use the latest bleeding edge XYZ.

crucialfelix• 9 years ago

Some code is perfectly suited to TDD. Other code not so much.

I was just working on something with a bunch of tangly functions that measure and remap data and prepare it for sonification as sound events.

I keep jest running and the workflow is much quicker and more satisfying than any other way of hacking.

krmboya2• 9 years ago

What about a kind of middle ground, doing a 'spike' when figuring out stuff, what kind of thing you should build, what the design should look like, etc then follow up with TDD to stabilize the identified interfaces and produce tests that act as a system health check?

Ok, for consultants, perhaps they end up doing the same kind of things for different clients to the extent that they can just jump in doing things TDD from the very beginning.

poushkar• 9 years ago

That's exactly how I work (web development) and I am really happy with it so far. First, I am playing with a throw-away code to understand how I want it to be. Then, I write some tests based on the acquired understanding and then finally working code. I can even copy-paste some parts of the throw-away code if they were correct initially.

I see my designs being damaged by tests sometimes, though but in tolerable amounts, and I am happy to compromise.

weberc23• 9 years ago

The main benefit for TDD in my mind is that it mostly makes it painful to write spaghetti code. When I'm reviewing something that looks too integrated, I just ask for a unit test for that particular piece of functionality, and the author is effectively forced to go back and refactor. After going through this a few times, they learn to think about their design before they write code. Of course, many dynamic languages defeat this by offering hacks like Python's mock.patch which let you nominally test spaghetti code...

srj• 9 years ago

TDD is about creating tests for your requirements, and then writing code to make them succeed. The reason it doesn't work is because most medium/large feature changes don't fully realize their scope and requirements until they're well along into development, making the earlier tests an unnecessary drag.

Writing unit tests at all is independent of TDD. After you get the feature working, you write those to verify the program does what you think it does and to think through failure scenarios. Most importantly they make sure that future changes do not break the functionality you just implemented. I think asking for unit tests is important for any true bit of functionality in a large system.

weberc23• 9 years ago

Fair enough. The benefit of TDD them in my mind is that it keeps undisciplined developers from wedding themselves to a bunch of untestable code and then getting frustrated when asked to add tests in a code review. Whether or not this is the stated purpose of TDD is a different matter.

shubb• 9 years ago

Interesting that you mention dynamic languages. I think that a lot of why people do TDD is that you can't reliably know if a program in a dynamic language has basic issues unless you run it.

The same is partially true for manual memory managed languages.

You need to push towards 100% coverage in order to replicate the advantage you get in a statically typed language like Rust.

weberc23• 9 years ago

Yes, the better static analysis you have, the less you need to depend on runtime checks, but Rust makes a lot of tradeoffs which ultimately make it a poor choice for most application development (steep learning curve notwithstanding). There's a whole suite of static functional languages that give you the same strong static guarantees, but without the headaches of borrow checkers, lifetimes, boxes, etc, etc. Beyond that, there is Go which gives you some rudimentary static typing (a 99% improvement over dynamic languages), world-class tooling, a great deploy story, etc. In my mind, Go is the sweet spot for the demands of modern application development.

haskellandchill2• 9 years ago

TDD works for me and the rest of Pivotal Labs, maybe 1000 or so people. YMMV

henrik_w• 9 years ago

One of the key benefits for me is the mindset (fostered by TDD) to make as much as possible of the code (unit) testable. This naturally leads to less coupled code, because otherwise it is not possible to test it in isolation. So the fact that you start with the aim of unit-testability leads to better designs.

24gttghh• 9 years ago

Test Driven Development? All these acronyms and not once is it spelled out in the article or the discussion! Is it like saying HTTP or DNS to most people? I'd honestly never heard of it...but the concept seems logical from a high level.

chubot• 9 years ago

The tests get in the way. Because my design does not have low coupling, I end up with tests that also do not have low coupling.

Not to be smug, but I feel like this is a rookie mistake I learned 10 years ago immediately after starting TDD.

The slogan I use in my head is that testing calcifies interfaces. Once you have a test against an interface, it's hard to change it. If you find yourself changing tests and code AT THE SAME TIME, e.g. while refactoring, then your tests become less useful, and are just slowing you down.

Instead, you want to test against stable interfaces -- ones you did NOT create. That could be HTTP/WSGI/Rack for web services, or stdin/stdout/argv for command line tools.

Unit test frameworks and in particular mocking frameworks can lead you into this trap. I've never used a mocking library -- they are the worst.

There are pretty straightforward solutions to this problem. If I want to be fancy then I will say I write "bespoke test frameworks", but all this means is: write some simple Python or shell scripts to test your code from a coarse-grained level. Your tests can often be in a different langauge than your code.

The last two posts on my blog are about this:

"How I Use Tests": http://www.oilshell.org/blog/2017/06/22.html

"How I Plan to Use Tests: Transforming OSH": http://www.oilshell.org/blog/2017/06/24.html -- I want to change the LANGUAGE my code is written in, but preserve the tests, and use them as a guide.

And definitely these kinds of tests work better for data manipulation rather than heavily stateful code. But the point is that testing teaches you good design, and good design is to separate your data manipulation from your program state as much as possible. State is hard, and logic is easy (if you have isolated it and tested it.)

Summary: I use TDD, it absolutely works. But I use more coarse-grained tests against STABLE INTERFACES I didn't create.

daxfohl3• 9 years ago

This is terrific. You know, I've spent the last ten years perfecting coding strategies around unit test frameworks and mocks. I'm really really good at that. Really. I won't be humble; if somebody wants this, then I'm one of the best in the business. Yet, I'm slowly coming to the realization that that's a perfectly useless skill. Perhaps, even a negative skill.

It depends on the project, but for most projects I've worked on, the most difficult parts are the integrations with external systems. Figuring out what headers you need to pass in a call to Facebook, or what certificates you need to access some third-party API, or what data to send over USB to activate some device. Unit tests / mocks let you blithely ignore all those things. You mock them out, hide behind an interface, write your "application code" that uses these interfaces to do whatever your application does, make unit tests with mocks that behave the way you'd like, and viola your app is done! With almost 100% code coverage even! And it's even fairly well-designed with fairly low coupling. Except, it doesn't work at all, the hard work is still ahead of you, and your interfaces are all probably leaky abstractions that you're going to have to change substantially to make it work for real.

Anyway that's the hole I've dug for my current project. I'm pretty quickly coming to the conclusion that I need to unlearn quite a bit, retrain my instincts. I like your posts. Not even much for the content, but mainly for the concept. Rather than cargo culting onto "unit-testing-in-framework-X-to-achieve-100%-code-coverage-because-that's-how-you-make-sure-your-app-works,-right?", it's more of an intentional approach. Step 1: determine what we really need to make sure of, step 2: determine the best way to achieve that.

Ultimately, what I think is wrong with TDD as most people know it, in a word, is that it's a shortcut. It's easy. You populate your mocks with fake data and it's infinitely repeatable so yay. Populating an actual database with fake data and making sure it's deleted/refreshed/whatever between tests is difficult. But that doesn't mean it's not the right thing to do.

bluGill8• 9 years ago

I can argue both sides of this (in fact I have).

I would response here that you need to consider your facade design pattern. You should have a facade that you test your code with by careful mocks and fakes. Then the facade translates between your code (which now works) and the API. Particularity if the third party is infamous for breaking changes all the time you want to ensure that when things break you only have to figure out what they changed and fix the glue code.

Of course if all you have is glue code (this is likely: a lot of real world problems are just getting data from one system to another) there is nothing to test.

nvarsj• 9 years ago

Thanks for this. TDD against coarse interfaces as you put it is the correct approach. Sometimes called end to end tests. The use of TDD at the class level, with mocking hell, is the cause of most of TFA's issues.

atom-morgan• 9 years ago

The use of TDD at the class level, with mocking hell, is the cause of most of TFA's issues.

What's your approach with testing? Do you typically do E2E tests only?

dc2• 9 years ago

Writing TDD tests made me a better developer because it pointed out just how coupled my applications were.

corpMaverick• 9 years ago

Title should be: "TDD did not live up to MY expectations".

TDD is sort of an art more than a science. You have to know when and how to do it. You also have to know how much as the marginal utility diminishes very fast.

dkarl2• 9 years ago

When you look at the TDD evangelists, all of them share something: they are all very good – probably even great – at design and refactoring. They see issues in existing code and they know how to transform the code so it doesn’t have those issues, and specifically, they know how to separate concerns and reduce coupling.

I think one of the selling points of TDD, and something I hoped for from TDD, was that causation went the other way, and writing tests would result in code being refactored to separate concerns and reduce coupling. Sadly, I've seen that it is possible to write code that is highly testable but is still a confused mess. What's more, TDD as promoted encourages people to confuse the two, resulting in testability being used as a reliable indicator of good design, which produces poor results because it's much easier to make code testable than it is to make it well-designed.

I've also seen people mangle well-factored but untestable code in the process of writing tests, which can be a tragedy when dealing with a legacy codebase that was written with insufficient testing but is otherwise well-designed. A legacy codebase should always be approached with respect until you learn to inhabit the mental space of the people who wrote it (always an incomplete process yet very important), but TDD encourages people to treat untested code as crap and start randomly hacking it up as if it were impossible to make it worse.

This unfortunate (and lazy) habit of treating testability as identical with good design is not a mistake that good TDD practitioners would make, but I think they did make a mistake in the understanding of their process. My guess is that when those people invested effort into refactoring their code for testability, they were improving the design at the same time, as a side effect of the time and attention invested combined with their natural tendency to recognize and value good design. They misunderstood that process and gave too much credit to the pursuit of testability as naturally leading to better design.

I do think the idea of TDD is not entirely bankrupt, because the value of writing tests is more than just the value of having the tests afterwards, but I think its value is overblown, and people who believe in the magical effect of TDD end up having blind confidence in the quality of their code.

agentultra5• 9 years ago

I've also seen people mangle well-factored but untestable code in the process of writing tests, which can be a tragedy when dealing with a legacy codebase that was written with insufficient testing but is otherwise well-designed.

Have you read Michael Feathers' Working Effectively with Legacy Code? [0]

In his definition of legacy code it is any such code that has no test coverage. It's a black box. There are errors in it somewhere. It works for some inputs. However you cannot quantify either of those things just by "inhabiting the mind of the original developers." The only way to work effectively with that code base in order to extend it, maintain it, or modify it is to bring it under test.

This is far more difficult than it sounds with legacy code than with greenfield TDD for the aforementioned reasons: there are unquantified errors and underspecified behaviours. You can't possibly do it in one sweeping effort and so the strategy is to accept that tests are useful and to add them with each change, first, before making that change and using the test to prove the change is correct.

Slowly, over time, your legacy code base surfaces little islands of well tested code.

You have to be deliberate and careful. You have to think about what you're doing.

This is a much different experience than writing greenfield code. TDD is effortless and drives you towards the answer in this case.

[0] https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...

dkarl2• 9 years ago

Yeah, I've read it, I know the definition, and I understand the intention behind adding tests to legacy code. Unfortunately, TDD (meaning TDD as I've encountered it in print and in practice) encourages people to think that "no tests" is tantamount to "no value to preserve" and therefore "no risk of harm from refactoring." Maybe that's an exaggeration, but certainly some TDD practitioners think that they can't possibly harm a codebase by adding tests. Unfortunately, testing requires refactoring, refactoring is redesigning, and if you don't understand the design you're modifying, your changes can make the code less understandable, not more. Tests added after the fact impose the test-writer's understanding of how the system works, which results in chaos if their understanding isn't compatible with the understanding embedded in the existing design.

Also, in spite of that definition, there's a lot more to "legacy" than not having tests. Not having access to the original designer and not having access to the the requirements or domain understanding that influenced development are important handicaps of legacy code that are entirely separate from tests. Certainly tests added during development can capture some of this knowledge, but adding tests after the fact does not automatically recreate it.

These are both examples of the danger of trying to elevate one aspect of software development to a primary and sufficient role. "Take care of X and everything else will work out" has no known solution for software development, and any methodology is harmful to the extent that it encourages people to think that way.

ericgunnerson9• 9 years ago

Original author here...

Your writeup mirrors my personal experience, which was why I was such an advocate for so long. But it doesn't mirror my team experience at all.

I bought Feather's book when it first came out and liked it so much that I bought copies for a whole team out of my own pocket. And I talked about and taught the techniques to the team members.

I had high hopes, and a good team, but the results that we got were not what I hoped for. The result we got was a lot of small tested functions throughout the codebase ("sprouts" in Feather's nomenclature) - which I expected - but I didn't see any evidence of coalescing of those tests into something better - and by themselves, the sprouts made the codebase worse.

I ran into a number of cases where I would pair with developers who were looking to do something better than sprout - so they could fix a whole class or area to be better - and the best answer I could give them is, "give me a morning and I can probably come up with a good solution", which doesn't really help. Some code is just aggressively hard to test.

And I should mention that this was pretty much the perfect environment to try this; I had a team without shipping pressure and a mandate from above to write better unit tests and sufficient time to train and pair with developers.

The approach we settled on was different. We spent our time looking for "targets of opportunity"; the problematic classes or groups of classes that were leading to real issues - bug farms, hard to modify, that sort of thing - and we took a targeted approach to replace them. The replacements were generally written using TDD.

blackoil• 9 years ago

TDD should not be taken as a religious dogma. The way I like it is, central business logic as pure functions, which have tonnes of unit test. While integration with other services and components sits on edge which do not have unit tests, instead integration tests. If I have a key piece of code, I wanna test, but would require lots of mocks, it is time to refactor.

programminggeek• 9 years ago

This is why TDD failed...

People don't like doing it.

So they don't.

The end.

Debugreality• 9 years ago

I've seen TDD used once really well in a university setting where it was used only for shared libraries/services that could be used by multiple other teams or departments but not on individual (front facing) projects.

Probably because only the best developers on the team worked on the shared services it eliminated the refactoring issue as well as ensuring shared services could be a lot more reliably and safely updated.

kevwil2• 9 years ago

This logic is flawed, and I'm not surprised it's coming from Microsoft. If the expectation is that (repeatedly?) making blind guesses quickly and (optionally) cleaning up the mess later is better than expressing an understanding of the problem domain before writing 'real' code, then yes TDD will not live up to those expectations.

seanmcdirmid3• 9 years ago

Note the site is http://blogs.msdn.microsoft.com. Any MS employee can start a blog here, and none of the content posted by an employee goes through a vetting process.

That being said, the logic is not really flawed at all. There will always be the real scottsman fallacy to deal with (what is real code? When does code become real?). TDD promotes writing tests first, whereas you might not even know what the spec is until you've gone through multiple iterations of the code, and along the way you'll have to refactor and rewrite to reduce coupling and reflect better understanding of the spec. Tests aren't bad, but writing the tests at the beginning doesn't really make sense in that context.

velox_io• 9 years ago

TDD is a nice idea, however TDD can add quite a bit of overhead. Upfront overhead, before writing any code. This isn't a problem if it is justified/ needed. Plus the tests can become more cumbersome when code changes, more baggage to carry.

Testing often becomes a KPI, and therefor is commonly gamed. Doing the bare minimum to tick '100% code converge!'. I'm a fan of contracts to test the spec and boundaries(whether human or other application) of software.

TDD requires discipline and experience; You could spend an infinite amount of time writing tests and never deliver, or the other extreme becoming incapacitated fighting bugs.

Our first priority should be crash-free software, THEN start to think about making it bug free.

baybal2• 9 years ago

As I remember, one Microsoft was one of the original TDD pushers. One person who worked there for over 20 years told me that "the peak TDD" at Microsoft was right around time of Win ME release

ern• 9 years ago

As I remember, one Microsoft was one of the original TDD pushers.

You may be mistaken: There was a well-known incident back in 2005 where Microsoft published guidance for TDD that was flat-out wrong (or at least not fitting with the mainstream understanding), and they had to retract it (in fact it was so far-out that they had to expunge the article from MSDN).

http://codebetter.com/jeremymiller/2005/11/18/microsoft’s-re...

One person who worked there for over 20 years told me that "the peak TDD" at Microsoft was right around time of Win ME release

Of course, Microsoft is big, and the broken guidance may not have reflected practices elsewhere in the company, but it seems unlikely that they were early TDD pushers if they hadn't grasped the concept (as commonly understood) by 2005.

garganzol• 9 years ago

TDD works exceptionally well. The secret sauce is to find the correct scope for tests. In my experience, integration tests are the most suited kind of tests for successful TDD.

fanpuns• 9 years ago

I appreciate that many of you (including the article author) are coming at this question with a lot of experience. I, however, knew very little about coding a year ago and learned with TDD as part of how I build almost every project. Although I think it's always the case that I might "be doing it wrong", it's hard for me to imagine now writing code without first writing tests. Part of this is, admittedly, that I'm still uncertain if my solutions or code will even work and writing tests helps me to both organize what I want to do and also verify that I haven't made silly syntax mistakes.

Was it harder to learn this way? Absolutely (at least I think so, but my sample size is 1). I can't tell you the state of despondency I was sometimes in learning test suites and trying to figure out how to test certain things all while knowing that I could just write the stupid code and inspect the output to see if it was right.

Also, I love to refactor. How do you refactor if you don't have tests to catch you when you break something?

PaulKeeble2• 9 years ago

You don't refactor if you don't have tests, or rather you do and you break stuff and take on a lot of risk. The reality is a lot of developers aren't working in teams with others and working on software that has a long future ahead of it, hacker news tends towards the smaller teams with short runways and its write it and throw it away as a strategy rather than refactoring.

draw_down3• 9 years ago

Not doing TDD doesn't mean not having tests!

As far as the beginner angle, it makes sense to me to stick to TDD when learning to code. There are already so many things to learn and understand, that sticking to one way of working would likely be helpful. The question for me would be whether it matters whether that method is TDD or something else; I suspect it wouldn't matter much.

oelmekki• 9 years ago

Not doing TDD does not mean not having tests, it just means writing them after writing the feature (this has been the usual way for a long time before TDD, although automated testing somewhat got very popular only a few years before TDD).

I too became a big fan of TDD when I was introduced to it by rspec, then a brand new testing tool. But those latest years, I grew tired of keeping fixing my tests despite having no regression in my codebase - just because implementation changed. I quit doing TDD, but mainly because I quit doing unit testing.

Nowadays, I only do integration testing. I've made a chrome devtool extension to generate capybara tests while I'm browsing, so that I can write my feature, then generate a test for it while doing visual QA in literally 5 minutes (this was something selenium IDE was doing in its time, I just made something a bit more modern to replace it). And since this is integration testing, my test won't break as often if I change the underlying implementation to do the same thing. I would even argue it makes my refactoring more pleasant : if I refactor correctly and end result is not altered, I don't even have to edit my tests (if it breaks, it may actually be a regression).

That being said, what matters is what makes you more productive. Don't take our word for it, it may not apply to you. Just keep wondering how you could make things better.

borplk2• 9 years ago

Unfortunately TDD has become a band-aid for lack of constructs that should be a part of the language in the first place.

A language that allows you to express the spec could be so much more useful.

UK-AL4• 9 years ago

If you implement the feature in the language, surely that language is expressing the spec.

borplk2• 9 years ago

That's not what I meant.

A language could give you first-class-citizen constructs for things like tests and constraints that could be compiler-enforced.

Some of that can be a part of the type system such as the ability to express "positive odd prime integer between 7 and 197".

Some of that could be in the form of other constructs such as function entry and exit guards.

You can "implement" all of that on your own as part of the program but that is not the same thing because semantic meaning and intention is lost.

However when it is a first-class language-level construct it has cascading benefits and tooling can also make use of it.

jasonkostempski• 9 years ago

Could have figured that out much sooner if someone had written tests for the expectations.

99_00• 9 years ago

The tests get in the way. Because my design does not have low coupling, I end up with tests that also do not have low coupling. This means that if I change the behavior of how class <x> works, I often have to fix tests for other classes.

At this point you should be realizing your code is untestable and needs to be refactored.

thewoolleyman• 9 years ago

Having done TDD mostly full-time for well over a decade, I have to agree, and it hits home with some past experiences.

You can end up with fully tested, TDD'd code, that is not well-designed - i.e. unnecessarily coupled, and not cohesive. Cohesion and coupling are the basis of most everything in good software design - e.g. all the letters in SOLID boil down to those two things.

The premise of TDD is that it's supposed to make that too painful to do to a damaging extent. But, if you keep ignoring the pain, perhaps in the name of a "spike" solution, or because you just don't have the experience or background to know what good design is, you will end up with a tested mess of spaghetti.

And that's even harder to untangle and refactor than untested code, because you have to figure out which tests are useful, useless, or missing. That just slows you down as you work towards a better design.

In these situations, scrapping the whole module, including tests, and starting over, is sometimes faster in the long run that trying to refactor incrementally with the safety net of existing tests (another of the main values of TDD).

-- Chad

(edit: typo)

soared• 9 years ago

Yeah I could google it, but its common practice to spell out an acronym the first time you use it.

remotehack2• 9 years ago

Software obeys its own dynamics. Some things work well. Some not quite the same. It's nice to see someone admitting that testing is good, rigid TDD; like rigid Agile or rigid Waterfall, are bad. Corollary, what our parents said still holds true; too much of a good thing is bad.

PaulKeeble2• 9 years ago

Microsofts own study of TDD showed that it definitely improved defect rates and they went fully into developing with it for Vista which is part of the reason for the delays. Nowadays large chunks of the API is automatically tested and this has allowed Microsoft to release changes must more often with a lot less manually testing.

So while this individual is finding his local team isn't getting the full benefits, Microsoft appears to be based on its own report on the technique and its outwards software release cycle changing.

mandude• 9 years ago

Wasn't Vista one of the Windows versions that was known for having bugs?

draw_down3• 9 years ago

I don't really have solid arguments against it, I just never found it particularly helpful, or ended up with a result that seemed to justify always working this way, or even defaulting to working this way.

cphoover• 9 years ago

TDD failed? What no it didn't? When was the last time you depended on the use of an untested library for a major project?

runald• 9 years ago

I've seen this too many times... TDD != Automated testing

faragon• 9 years ago

Tests are good for detecting code that is not working as expected, using them as a investment/insurance, based on a budget. However, in my opinion, TDD is often more about an obsesive-compulsive religion built on wishful thinking on programmers reaching the excellence by writing tests ad nauseam.

flashdance• 9 years ago

I develop software for radio towers. This was a very confusing headline and article. I only figured out halfway through that I was thinking of the wrong TDD.

Test driven development is one thing. Time division duplexing is very different. I'll have you know that the latter did in fact live up to its expectations!

Showerthought: I wonder if our TDD codebase is TDD?

thegigaraptor• 9 years ago

I hope nobody uses this article as ammo against TDD. The benefits are not felt immediately but when time comes for maintenance/updates, I'm working on my second port with a company. The first app had fantastic testing and I was confident in the work I delivered. This second app however was led by a developer who "needed to get things done" and I now have to wrap the v1 app in functional tests to validate that I'm delivering a solid port. If the company had enforced better practices sooner, they would have saved the time I'm spending on retesting the original app. This second iteration is test driven, hopefully the next dev has a better experience.

Also testing helps alleviate QA's workload by ensuring developers have not broken any tests and regressed functionality before we hand off to QA.

If you're hacking on an idea or learning, I can understand not testing, but if someone is paying to deliver code, deliver it with tests, period.

gedrap• 9 years ago

Personally, I found that TDD works very well for small modules / classes, etc, when there's little design to be done. In this case, you can focus on writing down the spec (test cases) and be fairly confident that it works by the time all test cases pass. Also, I agree with the author about complexity involved if one decides to go down the TDD way for large, complex systems. So, essentially, it boils down to picking the right tool for the job, and TDD is just a tool, like any others.

lucidguppy• 9 years ago

I'm not really convinced by this article or by the comments.

You can do exploratory code and TDD at the same time - you just have to write down what you expect the code to do first.

These criticisms of TDD are very weak because they don't spell out an alternative - every critic's vision of proper testing is different - and will respond "that's not what I meant".

blunte• 9 years ago

https://en.wikipedia.org/wiki/No_Silver_Bullet

hughperkins• 9 years ago

Since when did TDD fail? Which is not to say it needs to be applied systematically to everything. But there are often bits of code which are better off being correct, and TDD works well for those.

kgilpin• 9 years ago

Also, when a test relies on mocks it doesn't test the real thing, and doesn't guarantee proper behavior in the real world. I suppose this is obvious from the nature of mocks. And yet, if you can figure out a clean and fast way to test something without mocks, I think you're better off.

Along with the coupling problem mentioned in the article, these are the two reasons why I am writing a lot fewer mocked tests (e.g. Rspec) than before.

jv22222• 9 years ago

I'm not sure if the OP is advocating against using tests and ci completely, or just the process of writing tests first and then code... Any one got any thiughts on that?

maruhan2• 9 years ago

"The tests get in the way. Because my design does not have low coupling, I end up with tests that also do not have low coupling. This means that if I change the behavior of how class <x> works, I often have to fix tests for other classes. Because I don’t have low coupling, I need to use mocks or other tests doubles often. Tests are good to the extent that the tests use the code in precisely the same way the real system uses the code. As soon as I introduce mocks, I now have a test that only works as long as that mock faithfully matches the behavior of the real system. If I have lots of mocks – and since I don’t have low coupling, I need lots of mocks – then I’m going to have cases where the behavior does not match. This will either show up as a broken test, or a missed regression."

Simply comment them out temporarily?

"Design on the fly is a learned skill. If you don’t have the refactoring skills to drive it, it is possible that the design you reach through TDD is going to be worse than if you spent 15 minutes doing up-front design."

I don't quite understand how TDD means you skip up-front design.

namuol• 9 years ago

The main benefit of TDD:

It strongly encourages you to think of your code as several input/output problems.

When you apply this model of thinking at scale it tends to lead to a much simpler (read: less-complex) codebase.

sowbug• 9 years ago

This is the top-level comment that resonated most with the point I wanted to make.

TDD is good for training you to recognize untestable code. "Oh, yeah, that's a Law of Demeter thing... maybe we should just ask for the narrow object rather than the giant one that knows how to get the narrow one," etc.

Once you have that skill ingrained, it's reasonable to stray from strict TDD and simply remember to defend your code with adequate tests.

luord3• 9 years ago

This article made me feel good. Ever since I started doing TDD, I refactor a lot more and my code looks nicer.

Hopefully, I'm not falling into the other trap he mentions and getting into design that would be worse than 15 minutes up-front.

Sadly, I can't comment on anything else as TDD isn't practiced at all in my area.

kmicklas• 9 years ago

Most developers are bad at refactoring because most of the tools for it are terrible. Even at Google, something as trivial as renaming a function can be a monumental task.

mncharity• 9 years ago

Boston used to have a software craftsmanship meetup. One month, on the train going home, a few of us discussed "how to describe TDD". Someone had a teaching gig coming up. That night, I attempted to distill the views expressed by this couple of experienced TDD folks. Here it is, FWIW.

# What is TDD?

TDD is JIT-development, built on tests.

It's not developing things before you need them. That's too easy to get wrong. It's not built on reviews and approvals. They're too slow and fragile.

## TDD's JIT development with tests is:

1. Live in the present.

Focus effort on what is clearly useful progress now, not speculation.

Don't do planning or development before you need to. Because later, you will better know what is actually needed, if anything. Be restrained but thoughtful in judging how much of what, needs to be done now.

Don't put off integration. Until then, usefulness and spec are only speculative.

2. JIT-spec

Capture each behavior you care about as a test.

Keep them simple, small, and clear. A new spec is a failing test. A passing test means "done with that -- next!".

Don't stuff your mouth. Don't do lumps. Keep it bite-sized.

Don't spec it until you need it, even if you (speculate) you know where you are going later.

Don't worry about the spec having to change later. They usually do. If the speced behavior is clearly useful now to make progress, that's good enough. If it's something you don't really care about long-term, you can remove it later.

3. JIT-implementation

Keep implementation minimal.

Don't create speculative code. Do reactive implementation and refactoring. If you "might need it later", write it later, when you have clearer need and spec, and more tests available.

## About tests.

Programs have a few behaviors you care about, and many more that are implementation details. Test the behaviors you care about.

Tests redistribute development flexibility and speed.

* Behaviors pinned down by tests, are harder to change. Because you have to update the tests too. They're transparent but rigid, and change is slower.

* All other behaviors, become much easier to change. Because everything you care about is tested, implementation changes can be done energetically, without careful cautiousness and fear of accidental hidden breakage. They're opaque but flexible, and change is faster.

Distribute your transparency and flexibility wisely.

Some topics I'm notably unclear on include test refactoring and management.

* when does one delete tests?

* how are lines of development pivoted?

* how are different classes of tests handled? (eg: external spec commitment; less critical spec I still care about; sentinel spec, which I don't mind changing, but I don't want it to happen accidentally/silently; spec that's transient development scaffolding, and should be removed later; and so on)

Opportunities include:

* broader coverage of the strategy, test, and implementation layer activities

* description of how test suites and implementations change longer-term

* specific discussion of cross-cutting issues like risk mitigation

* tighter characterization of core (eg, all tests and code are a burden, and start with a high time discount, so create and retain only those which are clearly and currently useful)

matchagaucho• 9 years ago

Salesforce.com Developers are the highest paid in the IT industry and TDD is hardcoded into their development process. (All code is required to have 75% unit test coverage).

Correlation is not causation... but maybe it is?

peterburkimsher• 9 years ago

TDD supports the paradigm of Software Engineering as an Engineering field. Design, plan, build, test.

Chartered Engineers have qualifications for their skills to do this - whether it's building bridges, designing circuits, or making cars.

Most programming is not Engineering. It's scripting. Hacking together a quick solution to meet the user's immediate needs.

Huge businesses (including the company I work for) have some really weak points in their production flow. They're planning factory operations using some shoddy macros in Microsoft Excel thrown together by some businessperson with no programming experience. Management won't change it, because "it works".

Other fields of Engineering (civil, electronic, mechanical) have serious life-threatening consequences if they fail. Software rarely has that risk. (Insert comment about healthcare systems and WannaCry here).

For times when software carries serious risk, then TDD is still important! The rest of the time, it's a burden.

makecheck• 9 years ago

It’s important to not assume that tests and code will be written by the same person.

When tests are being created early, it’s actually a good excuse to have at least a couple of minds looking at the same problem, instead of bottling it up into one person who ends up quitting next month. It’s an excuse to not just discuss the approach to use but have some code, where each person may realize that they hadn’t really thought about the whole problem or maybe didn’t understand it at all.

Other criticisms in this thread are still fair. It is certainly possible to waste a lot of time on tests for instance, and to build something that is too restrictive. Ultimately though, if you’re more than a one-person project, some form of “sketch it out first” is a good thing.

partycoder• 9 years ago

TDD forces you to design with testing in mind, also known as construction for verification.

If testing gets in the way is because the design doesn't emphasize testing.

Then, if you have high coupling, you have high complexity and a stronger reason to test.

js8• 9 years ago

I think people should in fact test data, not code. Looking at it from purely functional point of view, functions should be either proved that they do what they should, or they should be asserted and QuickCheck-ed. But what really needs to be tested is that the input parameters (i.e. data) conform to some "hidden" assumptions that we had when we wrote the functions. Because as we modify the program, or even why we modify it, is that these assumptions have changed.

AngeloAnolin• 9 years ago

This.

"developers are quick to pick up the workflow and can create working code and tests during classes/exercises/katas – and then failing in the real world."

The anathema of TDD is that people equate having well defined test cases to a solid product that brings the solution that the user wants. I have seen far more software projects boasting of >85% of code coversge for tests, but still failing spectacularly.

TDD failed because it was assumed as the magic wand that aligns the end product with what's on spec and the process that it would cover, but the reality of human behavior being merely coded to test cases is far out from reality.

romanovcode2• 9 years ago

Oh, finally the TDD fad is dying. Never got into it and always thought it is a complete waste of time.

I advocate to write tests only for critical algorithmic calculations and nothing else.

Integration tests matter 100x more (at least in webdev).

hdi2• 9 years ago

Never got into it and always thought it is a complete waste of time. I advocate to write tests only for critical algorithmic calculations and nothing else.

What great advice! While we're at it let's advocate surgeons didn't use sterile instruments cos it's a waste of time.. well maybe only for heart transplants.

romanovcode2• 9 years ago

Yeah, I bet you are one of those who also test your repositories and DB connections while mocking the DB response essentially testing database operations without even having an actual database in the back-end.

richardknop4• 9 years ago

Would it still be TDD when talking about functional tests? So no mocking. Or does strict TDD definition only include unit tests.

Because the general principle of writing a test case and then writing/editing code still applies with functional / integration tests.

And I have always preferred to use functional tests to test bigger components / packages based on their public interface then to write a unit test every small function inside the package.

Unit tests seem to be much more useful in situations when you know exactly what should your inputs and outputs be, for example if you are writing a function to transform data from one type/object to another. This is where unit testing shines.

But a lot development usually involves integrating / gluing together several higher level components together and passing data between these components and I much prefer functional tests there.

zubairq• 9 years ago

I wish I could upvote this article X10000000... I totally agree!

deweller2• 9 years ago

I grant the premise that TDD has drawbacks. But are they really worse than the drawbacks of not writing tests?

Code with no test coverage will have more defects and will be more prone to regressions.

For many projects TDD is the best we've got until something comes along that replaces it.

globuous• 9 years ago

I thought TDD meant doing tests before implementing code rather simply testing code.

So I always assumed someone testing his code wasn't necessarily TDDing, and that someone not TDDing wasn't necessarily not testing, just that she tests after implementation.

Is my understanding of TDD wrong ?

deweller2• 9 years ago

You are correct.

I incorrectly interpreted "don't do TDD" as "don't do tests".

lobut• 9 years ago

I always thought it meant DRIVING the design as well.

The term TDD gets conflated with unit testing, and testing in general that it gets quite confusing have a discussion without going into hyperbole.

throw7• 9 years ago

too bad about the RE on the REOI. But TDD really failed because it didn't identify SLG parameters. I don't know if I'd call it a failure though, SLG parameters are usually hard to know before the start of a project and, even, throughout.

cyberpanther• 9 years ago

Sometimes lowering your expectations are a good thing for everyone. Now we know the pros and cons and can use it appropriately. No one particular habit is going to solve all your problems.

https://www.youtube.com/watch?v=7gt4StirOzc

tomelders• 9 years ago

Off topic: But who's in charge of typography at Microsoft? The typesetting of their blogs and documentation are horrific. And what little I see of Windows looks just as bad.

sametmax2• 9 years ago

Another reason for the failure of TDD is the fact you need to be a very good programmer to be productive with it. Indeed, it requires you to be able to think your general API and architecture ahead.

Junior and 9-to-5 programmers suck at this. They are much better at tinkering until it forms a whole, then shape that into something that look decent and works well enough.

And we live in a world where they represent a good part of the work force.

You can't expect everyone to be a passionate dev with 10 years of experience and skilled in code ergonomics and architecture design while being good at expressing him/herself. That's delusional. And armful.

UK-AL4• 9 years ago

Not really. Core tenants of TDD are failed test -> Get it working -> Refactor into something nice.

sametmax2• 9 years ago

But you need to know what the working API must look like. Creating an API is a much harder task than you think. You are used to it so it seems natural to you, but I assure you I keep giving training in IT months after months, and most people are not very good at it.

HN is full of 10x devs and they live in an expert bubble.

mledu• 9 years ago

If anything I think this article makes a great case for TDD. If your developers aren't good at design and refactoring and that is showing up in your tests, that is an indication that your design needs to be refactored to be less coupled. TDD isn't a panacea, developers have to have some level of sense and see the signs of a less than optimal design. Pain in test creation is a great way of showing that as it simulates client code.

I also don't understand people thinking that you have to write the entire test suite up front. You build your test along with your code. You start simply and build up, this way if you don't have concrete specs your tests are helping you with the design by thinking about consumption as well as implementation.

hdi2• 9 years ago

I like the general assumption that TDD failed.

Failed at what exactly? Who would think 1 methodology would give them all they need to be a great software engineer?

If TDD supposedly failed, can we hear the process that succeeded at what TDD failed? Please extend an olive branch and enlighten the rest of us.

Because I tell yea, I can't even count the amount of "senior software engineers" I've encountered, that deploy untested production code daily to systems that help you guys buy your coffee in the morning, manage your money and pensions. Oh yea, and they all seem to think TDD is bollocks too.

When that percentage decreases and engineers like that become a rare occurrence, then we can talk again. Peace.

he0001• 9 years ago

For me TDD is mainly three things. Firstly it’s about testing myself so I’ve understood the task properly before writing any code at all. In this step I also can tell if my code is doing too much and therefore can tell if my method or function conforms to the “single responsibility” rule. Secondly it’s about maintainability and logical reason. A codebase where I don’t know what it’s supposed to do, or forgot about it, I can always rely on the tests to skip the parts that’s not interesting making me to move faster. Thirdly it’s about the ability to refactor and therefore evolving design. Even if this is a step in TDD you will always need to refactor since requirements changes over time. The solution you had is not the optimal solution anymore and therefore you must refactor anyway. Evolving design is a strength where you continuously strengthen your code while getting work done faster and faster since you can offload the reasoning on the tests, covering your back.

AFAIK TDD is actually the only way to produce code in a systematic way. When reading TDD driven code I can make certain assumptions which I cannot do with randomly produced code (there’s no system to the code). TDD code is developed automatically with tests in mind and are always a lot easier to test when you need to do it, and you always need to do it. (I would argue that there is possible code which is not testable as is, unless you refactor and then you don’t know what the code is doing the same thing as it did before).

If your tests get coupled with the code, I’d say it’s because either your method/function is doing to much or it’s a language problem, not giving you the necessary tools to ignore implementation details, which mocks usually are an indication of.

Since TDD is a systematic way of producing code (at least more systematic than not doing it), code which isn’t produced with TDD will not play well with TDD produced code since it won’t follow the same conventions, designs and possibilities.

TDD doesn’t automatically make the code more bug free, but I don’t believe that TDD cause more bugs just because you use TDD.

If programmers cannot learn or deal with TDD, you have a different problem on your hands.

alkonaut• 9 years ago

His argument is basically that with tight coupling, TDD is too hard and time consuming to pay off.

But part of the point of TDD is ensure that all code is testable, and testable means loosely coupled.

So you can't start TDD'ing on a bad and tightly coupled legacy codebase. You can do it on a greenfield project however. Greenfield is very much the "lab environment" he talks about. You control everything.

With greenfield projects comes another reality though: you often have to explore and sketch a lot. TDD does not work well for writing a dozen sketch solutions to something and throwing out eleven.

And that to me is the main drawback of TDD: it works poorly for very young code bases and it works poorly for very old ones (that weren't loosely coupled to begin with). It's a very narrow window where you can start using TDD in a codebase and that's when the architecture is first set, but the codebase hasn't yet grown too coupled. Such a narrow window means it's not very popular, for good reason.

pwm• 9 years ago

I think testing itself is the second-best thing short of proving correctness. It won't guarantee that your code is correct but ideally it greatly helps reducing bugs. TDD, as far as I understand, seems to promise more than just the benefits of testing. It promises an emergent design that produces a solution to your problem. I think this works well for some problem domains, like a lot of web/CRUD/LOB apps, and not so well for others, eg. the Sudoku solver mentioned in this thread. On the other hand a lot of real world problems can be successfully solved by solutions that are adequate but not optimal, ie. good enough solutions and TDD seems to be a viable strategy for these. I personally yearn working on problems where TDD based emergent design is not enough and human ingenuity/intelligence/creativeness is needed. Sometimes I bump into these but at the same time I realise that most of my day-to-day job involves problems that is solvable by TDD alone. That said, while all my production code has extensive tests, probably less than 50% has a test driven design and I'm content with that.

geebee2• 9 years ago

Over 405 comments, I am late to the party here, especially since this is just my 2cents.

I think TDD "failed" largely for creative reasons. And it didn't actually fail.

The reason I was willing to use the word failed, in quotations, is that I do think that TDD is dead in the sense that it's a stick that can be used to beat people into submission. There was a long series of debates on youtube with DHH and a few TDD advocates, titled "Is TDD Dead", and it's funny that I think DHH largely won the debate considering that I believe the answer is, clearly, "no, TDD is not dead". TDD remains relevant and useful.

And yet, I think the TDD proponents suffered a severe setback in that debate, severe enough that I'd consider it a pretty bruising defeat.

Why? Because the debate showed that debate is reasonable. That the position that TDD is dead can actually be defended. Here's the thing - a lot of TDD proponents denied the existence of a legitimate debate. There was right, and wrong. Blog posts saying that people who even question the value of TDD should be unemployable, that TDD might rightly one day have the force of law behind it, that questioning TDD is the modern day equivalent of medieval doctors denying the importance of sanitary conditions and washing hands. That sort of thing. I think that by the end of the debate, there were too many cracks in the TDD argument to deny that not doing TDD may, in fact, be a good way to write software. TDD may not be dead (or even close), but that sort of browbeating certainly was put to rest.

Some of it was what DHH called test driven design damage. But the biggest one was creative. TDD may simply not work for the creative flow required for many types of software development. It's like, to contrive an analogy of my own, requiring a writer to outline the next page before writing the current one. It's just too disruptive. You can justify it a hundred ways from Thursday, but if people doing it can't write software as well as people who don't, TDD will lose.

None of this is to understate the importance of test coverage. But write some code, write some tests, repeat - yeah, I think that works. Trying to force everyone to do TDD through a campaign of shaming and intimidation was a horrendous fail. That's was the outcome of the youtube debates - TDD advocates actually did defend the practice quite well, but they fell far short of a standard that would mean DHH shouldn't be employable because he question TDD.

Perhaps not all TDD advocates were that extreme, but it was a strong enough faction in the TDD movement that I don't think I'm finding extremists and using them as a straw man. That sort of browbeating really was part of the TDD culture, and I think that even the good parts of TDD, the parts we should keep and even evangelize as developers, are harder to defend because of these early tactics.

alexeiz• 9 years ago

This looks more like "Misunderstood TDD did not live up to expectations." It's obvious from the article that tests were written after the code. That explains the excessive coupling in the code and tests being hard to write and constantly getting in the way of code development. This is not "test driven development". This is bolting tests on top of already (poorly) designed and implemented code. Tests are an afterthought. They did not drive the design. No wonder it doesn't work well. The high coupling in the code has to be repeated in tests and it's a rather painful and fruitless exercise. Have tests been written first, it would have been clear which design led to lower coupling: the one it's easier to write tests for.

MichaelMoser123• 9 years ago

if requirements are not clearly understood then the tests will not be complete - now does that invalidate the need to write tests? I don't think so.

Now this problem is amplified when writing tests on top of mocks; if you don't understand the requirement of the next level (mocked level) then your tests will be very incomplete.

Still, having unit tests that are run with each build is much better than having no tests at all.

TDD did not live up to expectations

Related Stories