Paul D. Anderson Wrote:
> I know there are a lot of D programmers rooting for enhancements to the
> unittests in D (and I don't want to re-open that discussion), but are there
> any of the best and brightest among us who have developed a module to allow
> for named tests and tests that keep running following a failure, etc.
>
> I apologize if this is a question that's already been asked and answered.
>
> Paul
Nick Sabalausky's deferAssert is one take on it, though it's rendered a bit
verbose by mixin syntax. I'm writing a small module for this myself -- my main
goal is to provide simple and intuitive syntax, and I'm willing to give up a
little functionality for that. Here's what a typical unit test might look like:
unittest
{
begin( "testName" );
int foo = 3, baz = 42;
bool isOnFire() { return true; }
expectEqual! ( foo, 10 );
expectEqual! ( baz, 42 );
expect( !isOnFire(), "danger: code is on fire!" );
}
And here is a sample output:
Testing 'parser'... [OK]
Testing 'lexer'... [FAIL]
FAILED TEST: lexNumber
lexer.d(517): expected: pos == 6; actual: '8', '6'
Testing 'units'... [OK]
Testing 'teststuff'... [FAIL]
FAILED TEST: testName
teststuff.d(12): expected: foo == 10; actual: '3', '10'
teststuff.d(14): danger: code is on fire!
It integrates quite smoothly so far, using Runtime.moduleUnitTester() to set a
custom runner for all unit tests that tracks errors, test names, and so forth
and provides the comprehensive output listed above. I also added console text
coloring, so on Windows and Linux those "[OK]"s will be in bright green and the
"[FAIL]" tags in red. :-)
Having to use begin() at the start of the test is a bit of a kludge, and
ideally D would allow tests to be named by unittest("testName") { } or some
similar syntax.
Also, my expectEqual template is hurt somewhat by a limitation in D -- it uses
template alias parameters so that it can print a string representation of the
symbols that were given to it in a diagnostic message, e.g., "expected: foo ==
10". Unfortunately, alias parameters can only alias single D symbols -- so
expectEqual!(foo, 10) is okay, but expectEqual!(someArray[1], someFunc()) is
not.
In another posting here (
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=105682
) I suggested allowing template alias parameters to alias compound
expressions, which would solve the above problem and make unit testing much
more awesome. :D
Anyway, as my test module develops into something a little more robust and
finished-looking, I'd be happy to post the code if anybody is interested.
