unittests are really part of the build, not a special run

[ketmar via Digitalmars-d]

On Thu, 02 Apr 2015 08:37:26 +0200, Jacob Carlborg wrote:

> On 2015-04-01 21:25, Dicebot wrote:
> 
>> I 100% disagree. Having built-in unittest blocks have been a huge win
>> for the language and greatly improved quality of library ecosystem.
>> Value of standardization and availability is tremendous here.
>>
>> Only problem is that development of the feature has stopped half way
>> and there are still small bits missing here and there. All your
>> requested features can be implemented within existing unittest feature
>> via custom runner - while still running tests properly with default
>> one!
> 
> The the unittest block itself could have been easily implemented as a
> library solution, if we had the following features:
> 
> * Trailing delegate syntax * Executable code at module scope
> 
> module bar;
> 
> unittest("foo bar")
> {
> }
> 
> Would be lowered to:
> 
> unittest("foo bar", {
> 
> });
> 
> These two features are useful for other things, like benchmarking:
> 
> benchmark {
> }

executable code at module scope isn't really necessary, i believe. it's 
just a little messier with mixin templates, but i believe that it's 
acceptable:

mixin template foo(alias fn) {
  static this () {
    import iv.writer;
    writeln("hello! i'm a test!");
    fn();
    writeln("test passed");
  }
}


// and do it
mixin foo!({assert(42);});

// or with trailing delegate sugar:
mixin foo!{
  assert(42);
};


sure, `static this` can do anything we want; registering unittest 
delegate in some framework, for example.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150402/7396a981/attachment.sig>