[ris]

Don't let TDD destroy your architecture.

TDD encourages a form of programming where you build from the outside-in, building layer after layer of abstraction, putting off solving the actual problem until you get to the messy gooey centre where it ends up being a kludge. It's also very easy to make flawed assumptions in your original TDD spec which you don't realize until you get to that gooey centre, having wasted N days in the process.

I honestly don't tend to start anything until I have a basic idea of how it's going to work (not a fashionable idea these days), and find that projects end up with a much saner structure when they're built from the inside out.

So my preference is to start TDD once I've got a very basic version of something working, at which point you can start diving in to all the corner cases.

[BatteryMountain]

Seconded. Only ever add tests after you have a working version. Starting a greenfield project with TDD is a waste of time. Just get something out then start testing your assumptions with unit tests, even then, don't test the whole codebase, test your fundamental assumptions and core features (like user auth, roles, permissions and their invocations, esp if multi-tenanted).

[bitwize]

The way to do it using TDD is to do your greenfield development to the point of a working solution to elicit your fine-grained requirements, then throw that away and rewrite it using TDD. The first version is considered a "spike solution" and is not supposed to touch production.

In TDD, all production code must be written against some pre-existing test. Any code which does not meet this criterion is broken.

[ris]

I have never worked with that sort of time luxury.

[_tom_]

It's frequently faster. Half-assed designs will cost you time forever.

[ris]

Let's not start throwing pejoratives around, there is nothing half-assed about having an idea how your design will work before you blindly start coding probably-wrong stuff.

I've also found having apparent time-luxury to be a rather paradoxical thing, the more of it you have, the more people start spending it by creating bureaucracy and busy-work. It never gets spent how you expect it to be spent.