http://code.dlang.org/packages/unit-threaded
https://github.com/atilaneves/unit-threaded

What's new? Bug fixes and the dtest util.

dtest lets you point it at a list of directories, preferably just one called "tests" (that way there's less command-line options to type) and voilá, all tests in all subdirectories get run automagically.

The way I have it set up for my projects is I have a shell script called "dt" that calls dtest telling it where the unit_threaded library is. All my projects now have a "tests" directory separate from the main source tree. When I'm at the root dir of the repo, all I have to do is type "dt" followed by Enter and there go the unit tests wizzing along in parallel. Edit, save, "dt", repeat until the test run goes red. TDD nirvana.

If I ever have my way and this takes off, I'd _really_ like to type "dub test" instead of "dt" and have it figure out dependencies itself. One can dream.

So now I have my own little version of what the Go guys have with "go test", whislt keeping the advantages of what the library already did. No boilerplate. Stick modules in "tests" in any package structure and have them all run.

Atila

On Wednesday, 13 November 2013 at 13:18:39 UTC, Atila Neves wrote:
> http://code.dlang.org/packages/unit-threaded
> https://github.com/atilaneves/unit-threaded
>
> What's new? Bug fixes and the dtest util.
>
> dtest lets you point it at a list of directories, preferably just one called "tests" (that way there's less command-line options to type) and voilá, all tests in all subdirectories get run automagically.
>
> The way I have it set up for my projects is I have a shell script called "dt" that calls dtest telling it where the unit_threaded library is. All my projects now have a "tests" directory separate from the main source tree. When I'm at the root dir of the repo, all I have to do is type "dt" followed by Enter and there go the unit tests wizzing along in parallel. Edit, save, "dt", repeat until the test run goes red. TDD nirvana.
>
> If I ever have my way and this takes off, I'd _really_ like to type "dub test" instead of "dt" and have it figure out dependencies itself. One can dream.
>
> So now I have my own little version of what the Go guys have with "go test", whislt keeping the advantages of what the library already did. No boilerplate. Stick modules in "tests" in any package structure and have them all run.

Nice. :)

I agree that "dub test" would be even nicer.