Instance-specific unittests

Steven Schveighoffer schveiguy at yahoo.com
Fri Feb 17 08:07:27 PST 2012


On Mon, 13 Feb 2012 19:32:31 -0500, H. S. Teoh <hsteoh at quickfur.ath.cx>  
wrote:

> On Mon, Feb 13, 2012 at 07:15:18PM -0500, Steven Schveighoffer wrote:
> [...]
>> 3. If you are making classes like this, make *sure* all your unit
>> test helper functions are non-virtual!  Otherwise, if some code
>> instantiates with unit tests on and some off, you will have vtable
>> inconsistencies.
> [...]
>
> I usually just use version(unittest){...} at the top of the file to make
> module-wide unittest helper functions. I don't like modifying the thing
> I'm testing just by the act of testing it (e.g., adding class members
> when running unittests for that class). This may be a fact of life in
> quantum physics, but for testing code I prefer the "independent
> observer" mode of operation. :)

I do that in some cases too.  But if one of your arguments is the object  
in question, I feel it is cleaner because:

1. You are not potentially allowing free-instantiation of a template for  
all types
2. You have much better control over visibility/protection on a class  
member than a module member.

Technically, adding a final method does not change the object in  
question.  It's just a syntax convenience.  However, I like the fact that  
if the object is a template, I can control when the unit test  
instantiates, and whether or not the helper function is defined.

-Steve


More information about the Digitalmars-d-learn mailing list