Extending unittests [proposal] [Proof Of Concept]

Johannes Pfau nospam at example.com
Fri Sep 21 11:01:15 PDT 2012


Am Fri, 21 Sep 2012 19:15:13 +0200
schrieb Jacob Carlborg <doob at me.com>:

> On 2012-09-21 17:32, Johannes Pfau wrote:
> 
> > Well, I think we should just leave the basic unittest runner in
> > druntime unchanged. There are unittests in phobos which depend on
> > that behavior.
> 
> Yeah, this was more a philosophical discussion.
> 
> > Other projects can use a custom test runner like Jens Mueller's
> > dtest.
> >
> > Ignoring assert in a test is not supported by this proposal. It
> > would need much more work and it's probably not a good idea anyway.
> 
> There's core.runtime.setAssertHandler, I hope your changes are 
> compatible with that.

Oh, I totally forgot about that. So the compiler is already calling
into druntime on assert statements, so forgot what I just said,
setAssertHandler should work just fine.

> 
> > But when porting gdc it's quite annoying if a unit test fails
> > because of a compiler (codegen) error and you can't see the result
> > of the remaining unit tests. If unit tests are not independent,
> > this could cause some false positives, or crash in the worst case.
> > But as long as this is not the default in druntime I see no reason
> > why we should explicitly prevent it.
> > Again, the default unit test runner in druntime hasn't changed _at
> > all_. This just provides additional possibilities for test runners.
> 
> With core.runtime.exception.setAssertHandler and 
> core.runtime.Runtime.moduleUnitTester I think that's only thing I
> need to run the unit tests the way I want it.
> 

I didn't think of setAssertHandler. My changes are perfectly compatible
with it.
IIRC setAssertHandler has the small downside that it's used for all
asserts, not only those used in unit tests? I'm not sure if that's a
drawback or actually useful.


More information about the Digitalmars-d mailing list