In his most recent post Chris Hartjes looks at the concept of "test whenever" (vs TDD) development practices and how, sometimes, writing tests for things that are may get tossed when they're done may not be the best option.

Let's look at TDD vs. Test whenever. The trade-off being made here is not about quality of code or guarding against regressions. It's about opportunity cost. This had occurred to me but I had dismissed it as being "anti-testing". But I think I was wrong, and here's why.

He talks some about a presentation from Dan North< ("Decisions, Decisions") about when to test (not whether to test or not) and how he noticed his development team was being very productive, but with a "spike and stabilize" development method. He also talks about the concept of "opportunity cost" and how it plays a factor in when tests are introduced to the process.

The key to all this is being able to identify at what stage in this particular pattern your code is at. Is it still a spike, meaning you are working out implementation details and trying to figure out if it will even have the desired result? Or is it stable, providing solid value to the application as a whole and ready to be wrapped in tests to protect against regressions?