Here is somthing I'd like to be able to do with unittests

class Foo
{
 // stuff
 unittest(Foo function() dg)
 {
    Foo foo = dg();
    // do unittest on foo
 }
}


class Bar : Foo
{
 // Foo.unittest({return new Bar;}) gets run
}


I'm not sure how to handle issues about constructor variables (maybe some sort of opFactory or something)

another syntax that occurs to me would be to make the unittest a template that get specialized on an each of the derived types.

I'm not  to interested in the exact implementation but what I'm thinking of is the ability to enforce the Liskov substitution principle for classes (and preferably interfaces)

BCS Wrote:

> Here is somthing I'd like to be able to do with unittests
> 
> class Foo
> {
>   // stuff
>   unittest(Foo function() dg)
>   {
>      Foo foo = dg();
>      // do unittest on foo
>   }
> }
> 
> 
> class Bar : Foo
> {
>   // Foo.unittest({return new Bar;}) gets run
> }
> 
> 
> I'm not sure how to handle issues about constructor variables (maybe some sort of opFactory or something)
> 
> another syntax that occurs to me would be to make the unittest a template that get specialized on an each of the derived types.
> 
> I'm not  to interested in the exact implementation but what I'm thinking of is the ability to enforce the Liskov substitution principle for classes (and preferably interfaces)
> 
> 

It's not a bad idea, but I'd prefer to see unit tests usable (i.e. not run with the executable, named, run each one even if another fails, etc.) and reflectable from other software (i.e. have them run as part of a CruiseControl build, etc.) before I see this. But if we get this, we *definitely* need it for interfaces, too.