www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Instance-specific unittests

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
I discovered something really cool today, and I thought I'd share it
with my fellow learners:

The unittest block is used for inserting unit tests that are executed at
runtime before main() is called. They are very useful for inserting
little tests after a piece of complex code, to make sure it actually
works as expected.

What's cool is that if you have a unittest block inside a class or
struct with compile-time parameters:

	struct S(bool B) {
		void method() { ... }
		unittest {
			/* test method() for correct operation */
		}
	}

then the unittest will be executed once *per instance* of S.  That is,
if your program uses both S!true and S!false, the unittest will run
twice, once for each instance. This ensures that the unittest tests all
variants of the code introduced by the compile-time parameter, up to
what your program actually uses.

But what if your unittest wants to test for a specific behaviour in a
specific instance of S?  You could write, for example:

	struct S(bool B) {
		void method() {
			static if (B) {
				/* Behaviour X */
			} else {
				/* Behaviour Y */
			}
		}
		unittest {
			S!true s;
			assert(/* test for behaviour X */);

			S!false t;
			assert(/* test for behaviour Y */);
		}
	}

The problem is that now the unittest will still run twice, but each time
it does exactly the same thing. Here's where another static if comes in
to rescue:

	struct S(bool B) {
		void method() {
			static if (B) {
				/* Behaviour X */
			} else {
				/* Behaviour Y */
			}
		}
		unittest {
			static if (B) {
				S!true s;
				assert(/* test for behaviour X */);
			} else {
				S!false t;
				assert(/* test for behaviour Y */);
			}
		}
	}

But we can do even better: since inside the static if, the value of B is
already known, we take advantage of the fact that we're inside the
parametrized scope of S, and so we can refer to the current instance of
S just by referring to "S":

	struct S(bool B) {
		void method() {
			static if (B) {
				/* Behaviour X */
			} else {
				/* Behaviour Y */
			}
		}
		unittest {
			static if (B) {
				S s;	// here S == S!true
				assert(/* test for behaviour X */);
			} else {
				S t;	// here S == S!false
				assert(/* test for behaviour Y */);
			}

			/* Test here for behaviour common to both
			 * variants */
		}
	}

And here you have it: a very clean and concise way to unittest different
compile-time variants of a struct/class. 


T

-- 
Ruby is essentially Perl minus Wall.
Feb 13 2012
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 13 Feb 2012 18:12:15 -0500, H. S. Teoh <hsteoh quickfur.ath.cx>  
wrote:

 I discovered something really cool today, and I thought I'd share it
 with my fellow learners:

 The unittest block is used for inserting unit tests that are executed at
 runtime before main() is called. They are very useful for inserting
 little tests after a piece of complex code, to make sure it actually
 works as expected.

 What's cool is that if you have a unittest block inside a class or
 struct with compile-time parameters:

 	struct S(bool B) {
 		void method() { ... }
 		unittest {
 			/* test method() for correct operation */
 		}
 	}

 then the unittest will be executed once *per instance* of S.

[snip] As Jonathan suggests, it's once per instantiation, though I think that's what you meant. Dcollections has been doing this ever since the D2 branch was introduced (circa May 2010). I use the following idiom to great success: class SomeClass(T) { enum doUnitTests = isIntegral!T; static if(doUnitTests) unittest { ... // unit test using the assumption that T is integral type. } } // at bottom of file: unittest { SomeClass!int intv; // run int unit tests SomeClass!uint uintv; // run uint unit tests ... } One other really nice benefit is that you don't have to specify template parameters, just use the class identifier inside the unit test. I have found the following issues with doing stuff this way: 1. The more values of T you try to test for, the more difficult it becomes to make a "generalized" unit test. But for the most part, I've found that for integral types, you can do a lot with integer literals. Making helper functions that construct your object using the same literal parameters helps immensely. 2. It's not enough to just rely on your global unit test to instantiate just the right ones -- because a template can be instantiated by a user of your lib while in unit test mode, you never know in what mode your template will be instantiated. 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'd link to example source on dcollections, but dsource appears to be down (github here I come!) -Steve
Feb 13 2012