Detached unit tests

Timon Gehr timon.gehr at gmx.ch
Wed May 1 15:03:16 UTC 2024


On 5/1/24 15:44, Dom DiSc wrote:
> On Wednesday, 1 May 2024 at 12:55:01 UTC, Timon Gehr wrote:
>>> For a strawman syntax, let's do what everyone does ... overload 
>>> `static`!
>>
>> Looks useful, as usually you want to test the API. Maybe this should 
>> have been the default behavior for unit tests with `public` visibility.
> 
> No, white-box test is correct as default, as black-box tests shouldn't 
> be in the same file anyway.

Ddoc unittests have to be in a very specific place though and they are 
generating user-facing documentation, that as a result of being 
white-box may accidentally rely on internal implementation details and 
not actually work for a user, even though all unit tests passed. 
Essentially, this makes documented unit tests less suitable for their 
intended purpose:

> Documented unittests allow the developer to deliver code examples to the user, while at the same time automatically verifying that the examples are valid. This avoids the frequent problem of having outdated documentation for some piece of code.

https://dlang.org/spec/unittest.html#documented-unittests


> So, if you want your "logically black-box" 
> tests in the same file, it is good that you have to explicitly opt in.

Well, I guess we'll disagree on this, I think it is not good that you 
have to opt into doing the more restrictive thing because the compiler 
will not complain about it if you get it wrong. My idea was to make a 
difference between `public unittest` and `private unittest`, but I do 
not feel strongly about it.


More information about the dip.ideas mailing list