[taligent]

TDD in theory is a great idea. In practice it is dreadful.

Because what has happened is that the obsession with code coverage has meant that developers create a whole raft of tests that serve no real purpose. Which due to TDD then gets translated into unworkable, unwieldy spaghetti like mess of code. Throw in IOC and UI testing e.g. Cucumber and very quickly the simplest feature takes 5x as long to develop and is borderline unmaintainable.

It just seems like there needs to be a better way to do this.

[nahname]

The thing about practice is that it takes practice. Here are the issues you raised:

- Focus on code coverage

- Testing nothing

- Spagetti code from doing TDD

- IOC + UI/Cucumber takes long to write and run

I would have to say I agree, there is a better way to do this. My guess from your last statement is that you are relatively new to software. Don't mistake your teams poor practices for the practices not working. Try to promote better practices.

Tell your team code coverage only informs you on what isn't being tested. It doesn't help with quality.

Tests, like code, should be deleted if they don't do anything. Strictly adhere to YAGNI,

If TDD is producing spagetti code, you are doing something very wrong in your tests. The tests should be short and focused, just like your code base. Those tests are hard to write on a messy code base, which forces you to refactor, which leads to clean code. Maybe read up on the SOLID principles and other code quality practices to see what you are missing. Refactoring techniques can be very helpful too. This takes years to get good at.

Cucumber is over used. Read about the testing triangle (http://jonkruger.com/blog/2010/02/08/the-automated-testing-t...). My guess is that your team is focusing on the top levels. Those tests provide little long term value, fail without good explanations and can be complicated to write and maintain.

[Throwadev]

Unit tests are still useful sometimes. Everyone, when they first start out, goes overboard with how many tests they write, and can't tell the difference between what should and shouldn't be tested. The first couple of projects that are unit tested for a developer tend to have so many tests that are brittle that it slows the entire process down.

What I do now is, well, I'm going to actually test stuff while I'm coding anyway right? Regardless if I'm doing TDD or not. Well unit tests give me a useful harness where I can write those tests, instead of hundreds of Console.WriteLines. It's basically not much more effort than Console.WriteLine() style "testing", except you are left with some reusable artifacts at the end that may come in handy later on.

[anthonyb]

You're supposed to refactor your code. Layering tests on top of tests means that you end up spending more time maintaining tests than writing code.

Also, don't test stuff that isn't going to break, and avoid writing system and UI tests unless you absolutely have to.

[jasonlotito]

People always ignore the refactoring. They also look at the time TDD adds merely in terms of individual sessions. They don't look at the project as a whole.

> Also, don't test stuff that isn't going to break

Hah! =) But how will I prove that i++; is actually incrementing i!

[anthonyb]

Well, if the incrementing is part of a method somewhere, it probably should be tested, but as part of testing the method, not the ++ itself.

Usually it's more like people testing the basic mechanisms of frameworks or libraries. In some cases it makes sense, eg. if a library that you're depending on is a bit dodgy, but usually it's just a waste of time.

[taligent]

The problem is that that right now in the software industry:

TDD, Agile, Scrum, XP etc are a religion.

And a lot of people have managed to make their lives easier by making the teachings of this religion mandatory. So what I've been witnessing the last few years is that saying "no I don't think we need a test for this" is a position that will get you no where. So instead every one just puts up with longer and longer build times and spending more time each day fixing broken tests.

[anthonyb]

That's an overly cynical take - I've seen both TDD, Agile and Scrum work really well. In any case, refactoring is part of the religion too, so it shouldn't be too hard a sell for you.

And it'll fix build times and broken tests! :)

[pjmlp]

Come work to the enterprise world where no one cares about whatever the cool kids are proposing.

If the customer does not request for unit tests on the contract, usually no program manager is enforcing people to waste time writing them.

[rdfi]

I would argue that this type of discourse is not useful. There people putting effort into properly assessing the usefulness of using tdd. Personal anecdotes are of little value. See http://blinkingcaret.wordpress.com/2012/10/02/tdd-bdd-add-ev...

[ollysb]

It sounds like you've had some bad experiences. I'm not sure that you could attribute unwieldy spaghetti code to the use of TDD though. Do you believe the projects you've worked on with TDD would have been in better shape without TDD?