While pondering on the merits of TDD the other day something struck me. Test Driven Development really has little to do with testing. It's a bit like saying that C# is a testing language because it supports boolean expressions. The real essence of TDD is defining a contract of intended behavior. I call it Intention Safety. Intention Safety is a bit like Type Safety, but rather than enforcing the type it enforces the intended behavior of the program.
But if you follow this line of thought, TDD really seems to be lacking. Type safety is controlled by well defined types. Either something is compatible with a type or it isn't and we get a compile time error - it's pretty much black or white.
The contract for intended behavior in TDD is far weaker. In some ways it's like playing a game of Taboo. You can specify anything you want so long as you don't specify the exact behavior. If Type Safety were to work the same way that TDD does, we wouldn't have types but instead a type definition would be a series of patterns that are used to recognize a type. Think how much harder programming would be.
So why can't TDD be as good as type safety? Admittedly defining much less articulating behavior is a very difficult thing indeed. There are projects such as the endeavors of Intentional Software that still haven't come to any real material fruition.
But perhaps one day it will be this simple. Perhaps one day when we define a function, we don't just have type safety for the bits coming in and out. Perhaps we'll also have a little declaration at the start of the function that defines the intended behavior of the procedure. Or perhaps that declaration will be the procedure itself and there won't be any real code. And TDD won't really be needed any more.
Some food for thought.