Why think unit tests should be in their own source code hierarchy instead of side-by-side

[H. S. Teoh]

On Sun, Mar 25, 2018 at 04:22:32PM +0000, pineapple via Digitalmars-d-announce wrote:
> I really like `unittest`. It's my personal conviction that a developer
> should not be able to view the documentation, tests, or implementation
> for some part of a code base in isolation. `unittest` makes it easier
> for me to work this way.
> 
> Automated tests are vital for stability and documentation is vital for
> maintainability and making it possible for others to understand your
> code.  But when they aren't right there in the same place as the
> implementation, I've noticed that it is the inevitable habit of
> developers to think of tests and documentation as second-class, if
> they are thought of at all. The developer updates the implementation
> and doesn't think to update the tests or the docs. This happens a few
> times. Then instead of updating the tests to work with the updated
> implementation, the tests are discarded as an inconvenience. And then
> end users become confused by docs that have since become inapplicable.

Exactly. This is why inline unittests are one of the best design
decisions ever made in D.  Along with built-in documentation (in spite
of all ddoc's warts).

Before D, almost none of my code was ever thoroughly tested -- I just
couldn't be bothered to install, setup, write, and then keep in-sync a
separate unittesting system. Ditto for a documentation system.  I tried
DOxygen for one project, but it did not even get past writing a
Doxyfile. :-(  Fortunately, now I'm in the process of migrating that
project from C++ to D, and now I have 90%+ test coverage, integrated
into the build system so that it will fail loudly should any test fail.
A large part of the tests are inline unittests -- otherwise they would
just be too cumbersome to maintain and I would've given up long ago.
(The external testsuite is there only out of necessity, due to the
original C++ design; if I had the started from a blank slate, I would've
hands-down preferred inline unittests.)

D's unittests and inline docs (in spite of said warts) have
significantly (and measurably) improved the quality of my code. And the
fundamental reason is exactly as you said: proximity to the actual code
make a huge difference.  External docs does have the tendency of quickly
falling out-of-date, and external tests tend to get ignored and
eventually thrown out -- I've seen this with my own eyes in large
projects with large numbers of developers, where the code simply changes
way too fast for any external docs/tests to be kept up-to-date without
lots of external motivation (like an angry manager holding threats over
your head, :-P or an irate QA department complaining about regressions).


T

-- 
Philosophy: how to make a career out of daydreaming.