Re: TDD and BDD for emacs-lisp

[Xavier Maillard]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Xavier Maillard <xavier@maillard.im> writes:
>
>> Hello,
>>
>> for my next project (an IM tool), I would like to try to embrace TDD/BDD
>> methodology. I have never done this before and I even do not know the way I
>> will have to change my coding habits.
>
> For unit tests, there are various emacs lisp test frameworks.  It's
> rather easy to write your own too.

Yes, but the idea is not really to reinvent the wheel for me and I'd rather
stick with existing (good) projects if possible.

> However, if you want to perform integration tests, since you are
> implementing a communication tool, you will have to send data from one
> end, and receive it on another end, so, in another process, and check
> that it has been correctly received, etc.

That's the idea. I thought I could /fake/ some part of the tests with
stubs/mocks (I am not sure I understand the difference between these two
beasts though) so that I could simulate data exchange with the external
service. Am I wrong ? Do I really have to test the whole chain ?

> Once I had to test a MTA (SMTP filter), and I was in that situation,
> with messages composed and sent from emacs, and received in another
> process.  You may want to filter and test the logs too (check for error
> messages or other events).

Yes, good point.

> In this situation, I know of no test framework helping, and therefore I
> tend to write my own test modules or tools, specific to each situation.

Makes sense.

> Sorry, I cannot help you with code, it was a long time ago, wikis, DCVS
> and things like elpa didn't exist yet!

Oh man, are you that ... o . l . d ? (kidding :D)

[ snip ]

>> With ERT shipped with GNU emacs >= 24, there is no reason not to use it but
>> for BDD, I can see at least 2 (good) tools: ecukes and buttercup. Is there
>> any comparison chart somewhere ? 
>
> ERT is made to unit test emacs lisp code. I doubt it would be convenient
> to use when you have asynchronous and communicating processes. So it
> will be applicable only partially (on small local unit tests).

That's the idea. Given I'd rather starting with BDD and then TDD, that's not a
problem. I also want these tests to be the actual documentation/spec for
end-user (not a manual though).

Thank you Pascal.