[dcherman]

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]

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.

[eropple]

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

[moron4hire]

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

[eropple]

If there are changes to an interface that make irrelevant those tests, then you change those tests (and, if you're semantically versioning like you should be, you bump the major version number). I don't really get what you're objecting to. Implicit in doing TDD effectively is adopting the (light) burden of refactoring.

Yeah, people will delete tests because they refuse to refactor them. They're bad programmers. Don't work with them?