I disagree with the idea of tests as documentation or tests as determination of required functionality. The former is inadequate and the latter ignores why we code in the first place, which is to answer a need, be it a personal tool (I get tired of renaming music files) or a business need. Testing is secondary; not inessential, but secondary.
This is almost frighteningly backwards, akin to a 6000 year old earth. Requirements are NOT defined by tests, that’s … eerie. In real development a project begins with
- a requirements specification, defining a set of needs, describing that the development target will do, with no reference to how it is done. Example: an iPhone application that will be used to sell prepared food, in what geographic area, within configurable hours from configurable vendors
- a functional specification, describing the components that will be developed; continuing with the example, describing the database schema and the high-level objects and their methods and method parameters
- in some cases, not so often because it is too volatile, would need to constantly be updated, an implementation specification. This would describe how the code will actually be done. Because we always learn unanticipated things as we develop this document would have to be revisited and revisited, so only some companies bother with these, or leave them alone until release and then update them for maintenance programmers. This is the big problem with TDD, pretending you know before coding that the interfaces and behavior are supposed to be. That is, simple, not how it works in real life.
REAL testing, the kind that has value, is based on the functional specification, and it is this that testers write to. This is what blackbox testers use as the basis of their regression suites.
Your idea is that there are none of these, that the tests take the place of the requirements specification, which sound to me about as sensible as using a canoe oar as a screwdriver. That is a completely backwards approach to writing software. Have you never heard of these documents? You talk like defining the methods is some new and novel idea. What did you do before?
I think the important thing is that we do test our work. And there is no way that will be done well by the developer alone, thirty two years of experience have taught me that on every single project I have ever done.
I’m not going to say anymore about write tests before versus write tests after; the former will mean revisiting the tests, which is a little wasted time but not the end of the world. Disposing of documentation, eliminating blackbox testing, these are dangerous ideas.