<div dir="ltr">Does the proposal handle multiple unittest blocks?<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 13, 2014 at 9:02 PM, H. S. Teoh via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Aug 13, 2014 at 06:10:54PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:<br>
> Destroy <a href="https://issues.dlang.org/show_bug.cgi?id=13291" target="_blank">https://issues.dlang.org/show_bug.cgi?id=13291</a>?<br>
[...]<br>
<br>
1) How to add attributes to the unittest without them clashing with the<br>
function's attributes?<br>
<br>
2) How to parse ddoc comments for the unittest?<br>
<br>
3) Where should unittest block stand in relation to in/out contracts?<br>
<br>
4) How much can you realistically test on a generic type argument T,<br>
that you can't already cover with concrete types? I'm finding that the<br>
per-instantiation behaviour of unittest blocks inside templated<br>
structs/classes is rarely desired, esp. when you write ddoc unittests<br>
(because you want code examples in the docs to involve concrete types,<br>
not abstract types, otherwise they are of limited use to the reader).<br>
Because of this, I often move unittests outside the aggregate or enclose<br>
them in static if's. This suggests that perhaps per-instantiation<br>
unittests are only of limited utility.<br>
<br>
<br>
T<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
"A one-question geek test. If you get the joke, you're a geek:<br>
Seen on a California license plate on a VW Beetle: 'FEATURE'..." --<br>
Joshua D. Wachs - Natural Intelligence, Inc.<br>
</font></span></blockquote></div><br></div>