Postmortem: Template unittests are bad & you shouldn't catch Error

Mathias LANG geod24 at gmail.com
Thu Oct 22 17:14:54 UTC 2020


On Thursday, 22 October 2020 at 16:34:14 UTC, Adam D. Ruppe wrote:
> On Thursday, 22 October 2020 at 16:18:14 UTC, H. S. Teoh wrote:
>> 2) Ddoc's unittests require unittest blocks to be attached to 
>> the symbol they're documenting.
>
> The whole unittest as example thing was a mistake anyway. It 
> doesn't actually work at all (stuff can pass the test without 
> being a usable example due to scope contexts) and encourages 
> ugly, unusable examples because they are run as automatic tests 
> instead of you know, actually being written as examples.
>
> If I was in charge of it, the documented ones would have to be 
> like static, in that they don't depend on *any* context - the 
> compiler treats each block like its own pseudo-module and you 
> must import everything you use again (this guarantees you only 
> use public things and must demo a complete example) - and allow 
> them to be decoupled.
>
> In adrdox, I let you tag them with an ID, then embed by id in 
> the prose to insert the example where you want it.
>
> Maybe ddoc could do that too so you have some freedom to move 
> it around even if you reject the static paragraph.
>
> (or y'all ditch horrible ddoc and come to good docs. the 
> water's fine.)

Two pretty great idea. Do you have a bugzilla entry for them by 
any chance ?
I don't agree with the sentiment that documented unittests are a 
mistake though: they are a step up from documentation examples, 
because you are at least guaranteed they compile and pass in the 
right context. Examples in documentation might not even compile 
from day 1 because of a typo, or fail to compile when a symbol / 
language feature is deprecated or removed.

But making them context-independent is definitely an idea worth 
exploring.


More information about the Digitalmars-d mailing list