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