UnitTest and visual D

Jonathan M Davis jmdavisProg at gmx.com
Thu Feb 23 18:28:07 PST 2012

On Friday, February 24, 2012 03:12:08 Chris Pons wrote:
> Ok, thanks.
> I haven't run into version(...) yet. Would I be correct if I
> assumed that this version of void main: void main() {} would only
> run if -unittest was in the command line?



means that anything within that block is compiled in if the version symbol has 
been defined (either in code or via the command-line). For instance,

version(Posix) {}
else version(Windows) {}
else static assert("Unsupported OS");

would give you three different versions of the code. The Posix one gets 
compiled in on Posix systems. The Windows one gets compiled in on Windows 
systems, and the third block gets compiled in on everything else (in this 
case, with a static assertion so that you get an error when you try and 
compile with an unsupported OS). The version unittest is enabled when you 
compile with -unittest, so anything in version(unittest) gets compiled in.

> Also, what should be in a unit test? Test cases to make sure
> certain functions/classes are working as you intend them to?

Yes. Typically, after every function you put a unittest block with assertions 
that verify that that function is working correctly. And unit tests which 
tests combinations of functions can be useful as well. But regardless, the 
idea is to use unit tests to verify that your code works how it's supposed to 
and fails how it's supposed to (e.g. when certain input should result in an 
exception being thrown) so that you know not only that your code works 
currently but that your code continues to work when you make changes to it in 
the future. It makes for much more robust code and often actually increases 
the speed of development, because you end up with fewer bugs (since you catch 
them when you write the tests, which you typically do when you write the 

- Jonathan M Davis

More information about the Digitalmars-d-learn mailing list