Forum moderation policy idea: No overly combative debating

[Steven Schveighoffer]

On Saturday, 4 May 2024 at 01:16:43 UTC, NotYouAgain wrote:
> For example, there is a thread in DIP Ideas that wants to do: 
> "I want to propose that we provide a mechanism to semantically 
> detach unit tests from the scope they are written in. Such 
> unittests would be treated as if they were not in the same 
> scope or module".
>
> I proposed putting the unittest in a separate module, as that 
> would ensure it was out of the scope and semantically detached. 
> I pointed out also,  that was the same response that people 
> gave me when i asked for the same thing (i.e. the issue I have 
> with unittests outside the scope of a class, but within the 
> same module, still behaving as if it were in the scope of the 
> class.).

I'm unsure why it was deleted, but my response is that your 
suggestion does not, in fact, fix the problem. Documented 
unittests must go with the thing they are documenting. Putting 
them outside the module will not generate proper documentation.

unittests do not naturally associate with the code they are 
testing when written in other modules as well, I don't think 
that's a palatable answer. I want to write unittests close to the 
thing they are testing. This is a very nice feature of D.

As for `private(this)`, I do not agree that moving unittests that 
test public API outside the module is palatable. But also, 
`private(this)` does not fix that problem either -- you can still 
call `private` functions from within the module -- even if they 
aren't in classes, and documentation should avoid that.

-Steve