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