<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
It is, but with the extra twist of parse transforms that automatically<br>
export test functions (detected based on naming conventions). </blockquote><div><br>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.<br>
<br><br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">You could reuse that code if you want (it's LGPL).</blockquote><div>
<br>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.<br>
<br>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.<br>
<br><br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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)).<br>

</blockquote>
<br></div>
Well, feel free to come with suggestions about features that I could add<br>
to eunit (within reason - I won't try to compete with QuickCheck).<br><font color="#888888">
</font></blockquote><div><br>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.)<br>
<br>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.<br><br>Also, you will never use your weather satellite on New Eden City, Professor Carlsson!  I *will* stop your fiendish plan.<br>
</div></div>