Hello all,

Some unittests I've been writing for Phobos involve using assertThrown!AssertError to check that assert failures are indeed triggered where they should be.

Surprise surprise, this fails on the release unittest build, because of course the assertion statements are stripped out.  I assumed that using version(assert) { ... } to surround the assertThrown statement would fix this, but it doesn't -- the assertThrown keeps being called and keeps claiming that no AssertError was thrown.

I guess I could do version(release) {} { assertThrown(...); } but that seems kind of ugly.  Any alternatives?

Thanks & best wishes,

    -- Joe

I think using assert for unittests is a mistake if you ever going to test release builds. `std.exception.enforce` or something similar is a better match.

On 28/11/13 16:48, Dicebot wrote:
> I think using assert for unittests is a mistake if you ever going to test
> release builds. `std.exception.enforce` or something similar is a better match.

I'm testing an in-contract, as it happens.

The point is that code inside version(assert) should only be included if assert expressions are enabled, as described at http://dlang.org/version.html.  But even with version(assert) conditionals in place, the assertThrown is still called.

On 28/11/13 16:58, Joseph Rushton Wakeling wrote:
> But even with version(assert) conditionals in place, the assertThrown is still called.

Come to that, even if I do:

    version(release) {} else { assertThrown(...); }

then the assertThrown is _still_ called even in release mode.

On Thursday, 28 November 2013 at 16:01:06 UTC, Joseph Rushton Wakeling wrote:
> On 28/11/13 16:58, Joseph Rushton Wakeling wrote:
>> But even with version(assert) conditionals in place, the assertThrown is still called.
>
> Come to that, even if I do:
>
>     version(release) {} else { assertThrown(...); }
>
> then the assertThrown is _still_ called even in release mode.

Oh, oops, I thought your issue is exactly other way around, sorry. That looks like an issue in assertThrown implementation. probably worth a bugzilla entry.

On 28/11/13 17:04, Dicebot wrote:
> Oh, oops, I thought your issue is exactly other way around, sorry. That looks
> like an issue in assertThrown implementation. probably worth a bugzilla entry.

It's a bit mysterious.  Consider this minimal example:

    unittest
    {
        import std.exception, core.exception;
        assertThrown!AssertError(assert(false));
    }

... which should be fine in non-release mode and (potentially) problematic in release mode.  In fact it makes no difference whether you call:

    rdmd -main -unittest -cov assert.d

or

    rdmd -main -unittest -cov -release assert.d

... either works without complaint, which is not what you'd expect: you'd expect assertThrown to report an error in the case of -release mode.

Now, replace the assert(false) in the above with assert(true).  This time, in both cases, you get:

    core.exception.AssertError@assert.d(4): assertThrown failed: No AssertError was thrown.

... which is kind of in line with expectations, I suppose.

Now, wrap the line in question in version(assert) { ... } -- still fails in both cases.

Now wrap it in version(release) {} else { ... } -- again, still fails with both build/run options.

It's this last one which is really mysterious to me, because it suggests that neither version(assert) nor version(release) is being respected properly.

assert(false) is special and never removed, don't use it for testing assert code : http://dlang.org/expression.html#AssertExpression

On 28/11/13 17:20, Dicebot wrote:
> assert(false) is special and never removed, don't use it for testing assert code
> : http://dlang.org/expression.html#AssertExpression

Seems to make no difference if I replace it with

    int i = 1;
    assertThrown!AssertError(assert(i == 3));

... and tweak the assert accordingly (i.e. replace it with assert(i == 1) where previously I used assert(true)).

I have quickly tested it and looks like asserts are not removed from unittest blocks in release builds, only from normal code. Which does not seem to be documented on dlang.org but was probably introduced exactly to prevent existing tests from breaking in release mode. I have just learned something new :)

P.S. version(assert) does not seem to be working at all