This doesn't really sound like a new coding methodology, it's just describing a way to write good tests. TDD gets a special label because it flips the normal coding and testing process.
That's because TDD is primarily a design technique, not a test technique.
Tests are a (very) nice additional benefit, particularly because it has a simple way of ensuring coverage: only allowed to write production code if there is a failing test case, and only enough to make it pass.
I hate it as a design technique. It encourages you to write code you don't understand just so that it passes the tests.
For example. You want a function to test if a number is prime. You write the test: 4 is not prime, 5 is prime, 6 is not, 7 is prime, 8 and 9 are not. Now you write a function: n is prime if it is odd. Fails the tests: because it tells you that 9 is prime. You "fix" the code by checking that the number is not dividable by 3, it passes the tests, done.
Instead of writing code to solve a problem, you write tests to model the problem then you write code to pass the tests, there is an extra level of indirection and something may get lost along the way.
The only significant advantage of TDD I can think of is that you can't "forget" to write tests.
In fact, you are almost doing TDD, but missing the final step: Refactor Mercilessly
http://c2.com/xp/RefactorMercilessly.html
TDD directly helps you with interface design, that is how the pieces fit together. It helps you indirectly with the design of your implementations, because it enables this merciless refactoring.
"you write tests to model the problem then you write code to pass the tests"
Exactly! And once you have the code that passes the tests, and have written enough of it to have somewhat decent coverage for the problem-space, you can then refactor the implementation.
That is where you can go wild with your ideas, because you are only making changes to code that is already working and protected by a test-suite.
IMHO this isn't quite right, in my experience it's a programming technique. I.e. a way to approach programming applications. But it's not a technique for designing applications.
Sure sometimes you can "just write" an applications without caring about design. But in many many other cases just doing TDD without any proper designing will make you destined to fail to deliver a well working product. (At least in the field of larger applications which often need interoperability with all kind of other applications.)
It is a design technique, that is, one technique to help you design programs. It is not the only technique or a fully comprehensive and brainless methodology that you just plug into and out pop beautifully designed programs.
You still need to think, for example. And you can't skip the "refactoring" step, because that is where you get to do much of the design that TDD helps you with.
I'm a big fan of TDD and I personally get very little value out of the tests I write. However, they generate considerably more value when other engineers start working on the code. Also, when I haven't looked at a code base for a sufficiently long time I'm effectively no longer the engineer who wrote the tests. In both of these cases they become wonderful because, by design, TDD tests capture intent.
I am a little leery of yet another buzzword though. Reading the article just made me think yeah, you should rigorously think about what you're actually specifying, whether it's by formal or informal reasoning. I would actually claim the code the author picked on was in fact correct by definition since it satisfied its tests. It just didn't do what the article author figured it should do. The "mutation" is just a relatively cumbersome way to think through strengthening the specification. It's not clear to me that it's more productive to identify gaps in an implicit specification by breaking one's implementation rather than strengthening the tests, but I wouldn't be surprised if I have done so in some cases where for whatever reason it struck me as more pragmatic.
I have a bad tendency to over complicate things because I often see many of the potential future complications and other aspects of the larger picture which I really should ignore at that point of writing.
In turn a TDD programing approach gives me a nice degree of value at the moment of writing. The larger and more complicate the resulting program will be the more value I get out of it.
> think through strengthening the specification.
Having a weak/incorrect specification is a very common problem on larger projects especially if the projects are writen by one company for a different company (and just them).
Through mutation testing your code won't help there, but similar practices can help in finding gaps and problems with a non-code specification, too.
