I've been through this thread:
http://forum.dlang.org/post/mailman.1454.1369104411.4724.digitalmar...@puremagic.com
I would like the named unittests, as describe there, but I don't
think it is in the works (if I'm wrong please let me know). So I
took an approach outlined here
(http://www.reddit.com/r/programming/comments/1edih2/dconf_2013_day_1_talk_4_writing_testable_code_in/c9zg3ry)
and created a minimal, simple scheme.
The support file is here: http://pastebin.com/tU9BuS3G
To use it:
- import the support file
- mixin an init routine `mixin UTInit!__MODULE__;` to your module
- Instead of using unittest blocks (or in addition) put code in
annotated functions.
`@UT void testFoo() { .... }
To run all tests:
`rdmd -version=UT --main program`
To filter by module (using regex)
`rdmd -version=UT --main program -m 'foo.*'`
To filter by test function (using regex)
`rdmd -version=UT --main program -t 'foo.*'`
I think the approach makes sense, but I am looking any
comments/criticisms on what may be missing or misguided.
The downsides as I see it:
- it is not standard
- it comes with a version, UT. So you can/should wrap all tests
in version(UT) to ensure they never make it to production
- all test functions must be at module level. Not sure if there
are any ramifications?
The pluses:
- filtering of test by module and function name
- it works along side of unittest. It can also work with others
like specd which is a nice way to describe tests and know when
things fail the location.
Thanks
Dan
