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

431–440 of 450 posts

Re: TDD did not live up to expectations

#431

Post by Dominator »

The biggest reason I like TDD isn't ending up with tests (that's a really nice side benefit though).

It's that I start writing how I intend to "use" the function/method, and thinking about how I'm going to make it testable (i.e. dependencies, etc) before even writing any of the code itself.

Then I can immediately start refactoring as soon as I finish writing the code, cleaning it up a bit before committing.

But the "test-first" approach has saved me countless times from unintentionally coding my way into a quagmire of dependencies, etc.

Re: TDD did not live up to expectations

#432

Post by bm2yogi »

taeric wrote: post #64
nostrademons wrote: post #37

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…

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…

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

Re: TDD did not live up to expectations

#433

Post by tokenizerrr »

ZoFreX wrote: post #413
tokenizerrr wrote: post #373

Earlier quoted context omitted.

But the code containing the bug is already there. The idea of TDD is that you write tests verifying behavior before there is any code.

This definition of TDD either supposes that it is possible to write software with zero bugs using TDD, or that your project ceases to be TDD as soon as a bug is discovered, or any other change is required. I propose this definition is not very useful.

I see that as just writing regular unit tests, business as usual. Not TDD, still very useful.

Re: TDD did not live up to expectations

#434

Post by ehsanu1 »

raverbashing wrote: post #78
atonse wrote: post #8

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

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

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

Re: TDD did not live up to expectations

#435

Post by daxfohl »

bluGill wrote: post #419
daxfohl wrote: post #333

Earlier quoted context omitted.

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

Why are you mocking those 3rd party things? I find in most cases I can test with the 3rd party thing in an integration style test. When the data I'm testing is trivial those 3rd party things can give me an answer in less than a millisecond and so my whole test is fast enough. I find that even when I need to do things like database query that setting up a database with fake data is enough that mocking the database isn…

See my other comment on this thread: https://news.ycombinator.com/item?id=14668402

Re: TDD did not live up to expectations

#436

Post by hyperpallium »

darylfritz wrote: post #93
hyperpallium wrote: post #18

Earlier quoted context omitted.

TDD is waterfall

Care to clarify this? I've seen plenty of Agile shops that practice TDD.

I was summarizing the parent. Although, a few other comments here better put my point, that TDD and unit testing in general, freeze your interfaces. Because interfaces define the functionality of modules, this forces your choice of modularity upfront.

This is fine, if your already have a fair idea of how to architect your problem. But if you don't, it makes it harder to refactor your interfaces (in the same way that clients depending on your interfaces does). Of course, you can rewrite the tests, since you have control over them; it's just harder. And you don't have the TDD raison d'etre reassurance of working tests for this refactoring, of interfaces. Higher level function tests, yes; unit tests, no.

Re: TDD did not live up to expectations

#437

Post by nvarsj »

chubot wrote: post #145

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

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.

Re: TDD did not live up to expectations

#438

Post by MichaelMoser123 »

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.

Re: TDD did not live up to expectations

#439

Post by raverbashing »

ehsanu1 wrote: post #434
raverbashing wrote: post #78

Earlier quoted context omitted.

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

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

Yes, that's why I say "making the test fail is useful" ;)

And yes, I've seen this happen as well, either you're not testing the bug-causing issue or you're using a "Magical Mock Library" where x.does_thing() just returns true and you thought it did the thing but it didn't.

Re: TDD did not live up to expectations

#440

Post by atom-morgan »

nvarsj wrote: post #437
chubot wrote: post #145

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

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.

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

Post reply on HN