Is phobos too fluffy?

[Andrei Alexandrescu]

On 9/19/20 5:15 AM, Imperatorn wrote:
> On Saturday, 19 September 2020 at 06:59:54 UTC, Jonathan M Davis wrote:
>> On Friday, September 18, 2020 6:05:39 AM MDT Imperatorn via 
>> Digitalmars-d wrote:
>>> On Friday, 18 September 2020 at 07:41:25 UTC, mw wrote:
>>> > On Friday, 18 September 2020 at 06:50:48 UTC, Imperatorn
> 
>> No. It's very common practice in D code to put the tests immediately 
>> after the code that they're testing. It makes it far easier to make 
>> sure that everything has tests as well making it easier to maintain 
>> the code and ensure that the code and tests are properly in sync. In 
>> addition to that, if a unittest block immediately after a symbol is 
>> marked with a ddoc comment, then it gets added to the documentation 
>> for that symbol, making it easy to add examples to the documentation 
>> and have those examples be tested whenever you run the unit tests 
>> without having to duplicate the examples and worry about whether 
>> they're in sync between the documentation and the tests.
>> ...
>>
>> - Jonathan M Davis
> 
> "It's very common practice"
> 
> Actually no it is not. D is the only example I've seen that routinely 
> does this. Virtually all other languages separate code and tests.

I just read that Python's doctest endorses the same:

* https://docs.python.org/2/library/doctest.html

It seems a matter in which reasonable people may disagree. I know Atila 
Neves doesn't like it, and he's reasonable. His reason is actually good 
too, of a practical nature at scale - build times/memory issues. I do 
agree with that reason, and that's about the only con I can every think of.

There are also a few discussion on that online:

* 
https://stackoverflow.com/questions/9022547/should-test-code-be-separate-from-source-production-code

* 
https://softwareengineering.stackexchange.com/questions/188316/is-there-a-reason-that-tests-arent-written-inline-with-the-code-that-they-test

The arguments against seem to come from folks who either never attempted 
to use inline tests and are doing a gedankenexperiment, or people who 
did try and were deterred by language limitations.

This is a short article in favor of doing it, or so it seems (not sure 
what the context is):

* 
https://techbeacon.com/app-dev-testing/6-reasons-co-locate-your-app-automation-code

For my money, the troika documentation-implementation-unittest is 
sacrosanct. It's the unit of progress. I honestly consider it unkind of 
someone to not provide all three together. And there's a synergy of 
sorts: in the projects with separate unittests, guess what - 
documentation is absent, too.

The advent of documentation unittests has made the matter all but 
motherhood and apple pie. Not providing such is almost going out of 
one's way to be a jerk to the user.