On 27/06/2014, at 12:37 AM, Alois Cochard wrote:
Interesting, It's sounds like your definition of `TDD` is what is my definition of `solving problem`.
Not exactly. It's problem solving/design activity PLUS recording aspects of your decisions as machine-readable tests.
My point was that I don't want to write test for a grammar that I might realize during further design that is wrong, this would be just complete wasted effort...
For one thing, tests can be automatically generated from a grammar. The first time I demonstrated this to a class of students, I said "now, here I've got this program that I wrote a few years ago and I know it works, this is just demonstrating how you can generate tests from a grammar." And then the very first generated test revealed a bug. At that point I was Enlightened. But the most important thing here is that a grammar and an API are not that different. The whole *point* of writing your tests first is that the interfaces we design are just another of the things we get wrong. It's way too easy to design an interface, code it up, start testing, and discover that something that should be easy is somewhere between difficult and impossible, and fixing it requires a redesign. (I would say that the original Document Object Model looks very much like something that was frozen before being checked this way. Certainly everything *I* wanted to do with it was unspeakably clumsy. Hooray for Haskell and document *value* models!) Writing test cases is one way in which "further design" happens; if a test that should be straightforward isn't, *that* is when you "release .. that is wrong". None of this is new. Back in the 1960s when people like Dijkstra were talking about top down design, they were talking about writing a program *as if* some helpful genie provided all the library support you needed, *playing* around and getting the design right, and only *then* implementing the library. (And when doing that, you do the same thing all over again.)
Instead I just test as a way to tryout my DSL... but really to me it does *not* relate to TDD... because I can do the same with just a REPL and the history of it...
Using a REPL (provided your system saves a transcript so that you can replay tests later) has two main problems: (1) you can't do it until the code and its interface *exist*, whereas writing tests earlier can save you time wasted on implementing the wrong interface (2) using a REPL is apt to be a bit haphazard; thinking about your tests off-line you can get more coverage with less work. Don't mistake me. I am *not* good at testing yet. The only reason I'm defending TDD is that I have after too many years finally learned that "if it isn't tested it doesn't work" is true of *MY* code, so the earlier I test something the less horribly embarrassed I'm going to be.
I wish that definition you use was the same understood by the industry, but it is not the way it was presented to me when I discussed with TDD enthusiast in the past... maybe things changed.
We are not called to be right. We are called to improve. Learn from many masters but obey none.