• BCS (21/21) Oct 09 2007 Here is somthing I'd like to be able to do with unittests
• Robert Fraser (2/32) Oct 09 2007 It's not a bad idea, but I'd prefer to see unit tests usable (i.e. not r...

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)

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.