Steven Schveighoffer:
> class ArrayList(V)
> {
> V take() {...}
> unittest
> {
> auto al = new ArrayList!uint;
> ...
That unit test is the test of just take(). To denote it in my code I add a
comment:
class ArrayList(V) {
V take() {...}
unittest { // Test of take()
...
Having an unit test block focused on just a method is good, because you can
move around or remove or add methods with no problems, keeping them close to
their unittests.
This is why in my recent unittest enhancement proposals (not in bugzilla yet) I
have vaguely asked for a way to link a unittest with something else like a
module, function, method, etc. But I have found no good and simple way to do
this. Even adding a name to the unit test doesn't solve this problem because
the compiler will ignore the unittest names:
class ArrayList(V) {
V take() {...}
unittest take_test {
...
>But I found that the unittests weren't compiling -- at all!<
This is a common enough problem with unit tests in D. So at the end of my
modules I add something like:
unittest { puts(__FILE__ ~ " unittest performed."); }
But this is not enough to catch your problem with unittests in templated
classes.
>I still would like a way to do a unittest inside a template that is
>technically not part of the instantiation. This allows you to unit test a
>function with a specific instantiation when it's not easy to build a generic
>unit test *and* you want the unit test close to the function declaration.<
This is not easy to solve with the way the whole D template system is designed.
>I hate to suggest static unittest :P<
Even static names get templated:
void foo(T)(T x) {
static T y;
}
void main() {}
that's why (for a different purpose, that is to define a constant shared by all
instances of a template) time ago I have suggested a "static static" for
templates, but it was not appreciated:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=100499
I don't have other ideas for you.
Bye,
bearophile
