www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - extension to unittests

reply BCS <ao pathlink.com> writes:
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)
Oct 09 2007
parent Robert Fraser <fraserofthenight gmail.com> writes:
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.
Oct 09 2007