Interesting, It's sounds like your definition of `TDD` is what is my definition of `solving problem`.

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... 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...

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.

Cheers

On 25 June 2014 22:44, Richard A. O'Keefe <ok@cs.otago.ac.nz> wrote:

On 26/06/2014, at 2:51 AM, Alois Cochard wrote:

> For me TDD is highly overrated, and is abused as a buzz word by recruiter...
>
> In the context of writing a DSL, how one can start by the test? It's just impossible...

I'm puzzled by this.

You have some sort of fuzzy idea for a DSL.
You're not sure exactly what it's going to look like,
but you have a fair idea of what you want to be able
to do with it.

So you write some code in your DSL, making it up as
you go. As you do this. you keep changing your mind
about what's a nice way to say things, and you go back
and revise earlier sketches.

After a few hours to a few days, you now have some
examples of things you'd like to be able to handle,
and can start mining them for a a grammar and you
can write some code to support them.

And guess what, you have written your DSL tests first,
because the examples you needed to do the *design*
work are precisely test cases that your code should
handle.

My understanding of the history is that this is
pretty much what happened when Erlang was designed.

A\ois

http://twitter.com/aloiscochard

http://github.com/aloiscochard