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