it's only module level granularity.

I agree that a library solution is the way to go, however there needs to be a way to have finer granularity, ie being able to call individual unittests.
I gave the reasons in the 2nd post in this thread. Syntax would be: unittest(test_fun){...}
having a short syntax such as this will make people use it.

digressing, I wish there would be a simple non-anonymous way to vote for such features, to see whether most people agree/disagree. It's easier than voting by email, which invariably gets lost in digressions (as I'm doing here).


On Tue, May 21, 2013 at 11:36 AM, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
On Tue, 21 May 2013 12:23:01 -0400
"Steven Schveighoffer" <schveiguy@yahoo.com> wrote:

> On Mon, 20 May 2013 21:52:51 -0400, Nick Sabalausky
> <SeeWebsiteToContactMe@semitwist.com> wrote:
>
> > So alright...Who's with me?!!! "Yeaaaa......!!!!!" (<-- Belushi
> > running out the door)
> >
>
> I think we can handle this without compiler help.
>
> The runtime is responsible for running unit tests.
>
> It actually provides a hook to allow you to override the unit tests.
> See here:
> http://dlang.org/phobos/core_runtime.html#.Runtime.moduleUnitTester
> (set in a shared static ctor).  All you have to do is just run the
> module's unit tests you desire.
>

Neat, I had no idea.

> I would argue the "stock" unit test runner could be configured by an
> environment variable to be able to run/exclude whatever you want.
> This is eminently fixable in the library with a small pull request.
>

I think that definitely sounds like the way to go.