Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TDD did not live up to expectations

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

231–240 of 450 posts

Re: TDD did not live up to expectations

#231

Post by thewoolleyman »

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)

Re: TDD did not live up to expectations

#233

Post by eropple »

willvarfar wrote: post #101
eropple wrote: post #87

Earlier quoted context omitted.

You can't do TDD when "bug-fixing maintenance". It's a contradiction in terms.

Curious. How so? Get a bug report. Write a unit test that reproduces the bug. Fix the bug. The unit test now passes. Check it in. Now its part of your growing regression suite. How is this not "test driven"?

Test-driven development refers specifically to building tests before implementations such that the impressions of the tests (which are communicating the external intent of whatever you're working on) are not colored by the particulars of an implementation. The tests you are writing are necessarily colored by the implementation you're fixing. This isn't bad (though I'd say it's less effective for most programming tasks than TDD), but it isn't TDD.

Re: TDD did not live up to expectations

#234

Post by insulanian »

hota_mazi wrote: post #88
Cephlin wrote: post #14

Earlier quoted context omitted.

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

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.

Thank you for saying this loud.

Re: TDD did not live up to expectations

#235

Post by srcmap »

lliamander wrote: post #191
taeric wrote: post #64

Earlier quoted context omitted.

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 aroun…

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 w…

TDD always worked for me.

All successful projects in my career had full functional regression test coverage.

For those successful projects, I made following conclusions:

  * My personal TDD process are:

    * Script enable - always run every night, every weekends.
         Output to html files to see overall green/red in

Re: TDD did not live up to expectations

#236

Post by taeric »

dang wrote: post #228
taeric wrote: post #225

Earlier quoted context omitted.

See my response in https://news.ycombinator.com/item?id=14664831 Basically, I'm not intending something different than what you are saying. I just picked a phrasing that can go both ways, unfortunately. :(

Ah I see. I still can't see how to read the GP the intended way but maybe it's just me.

Oh, to be clear. Just because I had intended it in one way, does not mean I was successful at it. I just didn't want to ninja edit a better wording under what others had already read. :)

Re: TDD did not live up to expectations

#237

Post by lojack »

falcolas wrote: post #20
gkop wrote: post #4

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 collaborat…

> 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,…

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

Re: TDD did not live up to expectations

#238

Post by jaggederest »

taeric wrote: post #125
amirouche wrote: post #106

Earlier quoted context omitted.

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 pr…

Rereading my post, I see where it sounds more strawman of the "entire wall of tests." I did not mean it to be the final test suite is written first. Instead, I intended that to be the wall that you will be passing in a given cycle. So, for a small development cycle, you add in some new tests that will be this cycle's "wall" of failing tests that you flip to passing. And don't take this to be an indication that I thin…

> So, for a small development cycle, you add in some new tests that will be this cycle's "wall" of failing tests that you flip to passing.

That's not right either. There is no "wall". Writing tests helps you write the code which helps you write better tests. It's mutual recursion, not a one-way waterfall.

Re: TDD did not live up to expectations

#239

Post by Jach »

willvarfar wrote: post #101
eropple wrote: post #87

Earlier quoted context omitted.

You can't do TDD when "bug-fixing maintenance". It's a contradiction in terms.

Curious. How so? Get a bug report. Write a unit test that reproduces the bug. Fix the bug. The unit test now passes. Check it in. Now its part of your growing regression suite. How is this not "test driven"?

Where's the design? (To me TDD was always championed to help specifically with Design as much as the vague Development. When using the vague Development too loosely you run into a recursive problem because writing tests is itself development so do you use TDD for your tests?)

Depending on how seriously you take the step of writing a unit test that reproduces the bug, you may be forced to refactor quite a lot of code to get that buggy section under test. Writing the test first can help guide your refactoring to avoid mocking the runtime world. But you're not designing anything, and it was all driven by the bug report.

Re: TDD did not live up to expectations

#240

Post by marcosdumay »

briandear wrote: post #74
AdmiralAsshat wrote: post #50

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 mea…

What’s RSA?

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.

Post reply on HN