[erlang-questions] Design strategies for a test suite

[John Haugeland]

> Do you happen to know how this is implemented?  I confess this actually
>> sounds a whole lot like the macro compile solution suggested earlier, but
>> I'm curious whether someone else has found a different way.
>>
>
> It is, but with the extra twist of parse transforms that automatically
> export test functions (detected based on naming conventions).


That's an interesting technique.  I've done something a lot more low-tech: I
just read through the module header with beam_lib, looking for a module
attribute called -testerl(), which indicates the test module.  Then there's
a behavior that implements the testing module interface, which gets, er,
called.  And zoom, off it goes.  I'm kind of operating in the reflection
mindset right now, so the interface provides a bunch of stuff that tells the
testing rig how the test module expects to be run under certain
circumstances, and yadda yadda yadda.  This is how you run an acceptance
test, this is how you run a detailed test, and I'm fighting the star trek
fan's urge to teach it to run a level six analysis on anything.






> You could reuse that code if you want (it's LGPL).


I appreciate the offer - it's very kind of you - but I'm an anti-GPL zealot
type (I'm all for the BSD style, and use the MIT license personally).
Besides, part of the reason I'm writing this is to come to better terms with
the problem, so taking someone else's work impedes my own growth.  Still,
thank you for the offer.

Besides, I kind of want to keep the entire tool in the raw code.  I've never
really been able to explain why, but I have a resistance to anything that
isn't done in the code.  A lot of it is about making the tool accessable to
novices, a lot of it is about making the tool easier for others to
understand, and a lot of it is about being fundamentally too lazy to figure
out what a parse transform actually is.  :D  But really, if there's a part
of this that I can do in code, I will, every time.






>
>  I'd appreciate someone else's perspective on what exactly constitutes
>> "neat" from the perspective of a testing suite.  The reason I'm implementing
>> my own is to get some functionality that I haven't found in any other erlang
>> test suites (with the exception of a commercial suite, but Mine Shall Be
>> Free (tm)).
>>
>
> Well, feel free to come with suggestions about features that I could add
> to eunit (within reason - I won't try to compete with QuickCheck).
>

Oh that's kind of what I was asking you.  And, well, I am trying to compete
with QuickCheck.  :D  I spent a while dicking around, reading people's
theses and watching crap on google video and etc, and I found a number of
techniques that I think are quite interesting and approachable for
implementation (as well as one that's quite interesting that I haven't yet
figured out how to implement, namely automatically derived models for path
coverage analysis.)

But it's good to know who my peers and betters (pardon me if I think of you
more as an arch-villian; my world is very comic book) are.

Also, you will never use your weather satellite on New Eden City, Professor
Carlsson!  I *will* stop your fiendish plan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080517/eca36359/attachment.htm>