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

351–360 of 450 posts

Re: TDD did not live up to expectations

#351

Post by mvindahl »

convolvatron wrote: post #257
YZF wrote: post #215

Earlier quoted context omitted.

I absolutely agree. It's also nice to know: * What's my confidence that the code will work correctly under different situations. * How maintainable the code is and related how easy is it to make changes. * How much time/effort does it take to create. It's funny (or sad) how the XP guys like Kent are always talking about doing the right thing and not being religious. This stops working when the people using it don't k…

i'm not a fan of tdd, and a huge proponent of testing in general. what you say about making bad changes to support tests really strikes a chord. in tdd environments the test harness is used as some kind of crutch to avoid having to have difficult discussions about what the product should* be doing - what makes sense. the test acts as some kind of oracle in the regard, even though it was written by an intern last spri…

Word. I have also worked on projects where existing tests were treated like holy cows. Deleting a test wasn't disallowed as such but it really required a convincing justification. Ironically, this made it especially hard to touch the inevitable subset of tests which had grown unreadable and which were not tracable to specs. Hence, they were often left alone, smelling riper with each passing year.

I like to think of production code as being inherently a liability, not an asset, and the same goes for test code. That's not to say that code, or tests, cannot be valuable; it's just that every line of code carries a cost to the business just by adding complexity to the development process and by taking up disk space and CPU cycles. Not all code offsets this cost, and a lot of tests certainly don't.

We should stop viewing tests like holy scriptures. Some add long term value, some add value during initial development, some should never have been written in the first place.

And on a side note, our tests should test the business requirements, i.e. they should be tracable to specs. There are a lot of tests out there which amount to little more than to "test" some arbitrary decisions which we made when someone initially fleshed out a class diagram.

Re: TDD did not live up to expectations

#352

Post by jalfresi »

charlieflowers wrote: post #293
yebyen wrote: post #204

Earlier quoted context omitted.

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

+1, that's a pretty cool idea >> 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.

Agreed! That actually makes it much more feasible to insert into my current workflow!

Re: TDD did not live up to expectations

#353

Post by collyw »

julian_1 wrote: post #302
srcmap wrote: post #235

Earlier quoted context omitted.

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

Do you write the tests first - before the code - and while still exploring the domain? That's the guiding principle of TDD. Writing tests after the code has been written - to lock down behavior, quickly identify breakage, and support refactoring is a valuable process. But it's not the original vision of what constitutes test-driven development.

Whenever I write tests first, they usually fail. I need to do some iterations of the test code as the "real" code until they work. Is there some reason why test code is expected to work first time, yet we need a ton of tests to verify that the "real" code works?

Re: TDD did not live up to expectations

#354

Post by poushkar »

krmboya wrote: post #110

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

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.

Re: TDD did not live up to expectations

#355

Post by pif »

hinkley wrote: post #65
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…

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.

Other parts of the world are, too :-)

Re: TDD did not live up to expectations

#356

Post by collyw »

danthemanvsqz wrote: post #279
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…

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'r…

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.

Re: TDD did not live up to expectations

#358

Post by crdoconnor »

lliamander wrote: post #241
srcmap wrote: post #235

Earlier quoted context omitted.

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

Sounds like you're doing the right thing. Note that not every one would agree that you are doing "true TDD" (due to your lack of "unit" tests) but that doesn't matter. What matters is that: a) you are disciplined in your commitment to quality b) you offload as much of the tedious, repetitive work to the computer as possible. Regarding unit tests and mocking, I have a similar opinion. I tend to test at the larger comp…

>Note that not every one would agree that you are doing "true TDD" (due to your lack of "unit" tests)

I think he's doing it right in spite of what other religious zealots may say. In my experience, unit test driven development causes three massive problems:

* Unit tests are intrinsically tight coupling.

* Unit tests require you to build a model for most things that you are testing against (e.g. your database). Building these elaborate models (i.e. using mocks) is prohibitively expensive when you have tightly coupled code but they're often still expensive to build (in terms of developer time) even when you have loosely coupled code.

* Unit tests are intrinsically unrealistic because they are built against models rather than the real thing.

In my experience unit tests work adequately for domains that are heavy on complex logic and light on integration (e.g. writing a parser). In domains which are light on complex logic and heavy on integration they fail badly (e.g. most business apps).

Optimizing for the overall speed of your test suite by using a more unrealistic test that catches fewer bugs is a massive false economy. CPU time is dirt cheap. QA and dev time is very expensive.

Re: TDD did not live up to expectations

#359

Post by richardknop »

tokenizerrr wrote: post #227
luhn wrote: post #109

Earlier quoted context omitted.

>> 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 It's a regression test, which is definitely TDD. The code in question is…

No that is just regular testing. TDD is about writing tests first, before other code.

Well, that's exactly this case. You would write a test to replicate/prove the bug and then - afterwards write the code to fix the bug, no? So you would write tests first.

Re: TDD did not live up to expectations

#360

Post by richardknop »

heifer2822 wrote: post #226
moron4hire wrote: post #79

Earlier quoted context omitted.

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

It's TDD. Just because the whole app wasn't developed with TDD doesn't mean you can't test drive a bug fix. There's a bug, you write a test, "this bug shouldn't exist", that test currently fails, then you write just enough code to fix the test, then refactor. That's TDD.

Exactly what I was thinking. The test ends up being written firs this case, before you write/edit the code to fix the bug. So it falls under strict definition of TDD.
Post reply on HN