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

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Mar 23 22:32:50 UTC 2018


On Fri, Mar 23, 2018 at 09:45:33PM +0000, Tony via Digitalmars-d-announce wrote:
> On Friday, 23 March 2018 at 20:43:15 UTC, H. S. Teoh wrote:
> > 
> > > I've worked on a project where the testing was separated from the
> > > code, and it was a liability IMO. Things would get missed and not
> > > tested properly.
> 
> That's where Test Driven Development comes in.

That's not an option when you have an existing codebase that you have to
work with.  You basically have to start out with tons of code and no
tests, and incrementally add them.  Having to also maintain a separate
test tree mirroring the source tree is simply far too much overhead to
be worth the effort.


[...]
> > Yep.  As I mentioned elsewhere, recently I've had to resort to
> > external testing for one of my projects, and I'm still working on
> > that right now.  And already, I'm seeing a liability: rather than
> > quickly locating a unittest immediately following a particular
> > function, now I have to remember "oh which subdirectory was it that
> > the tests were put in? and which file was it that a particular test
> > of this function was done?".  It's an additional mental burden to
> > have to keep doing the mapping between current source location <->
> > test code location (even if it's a 1-to-1 mapping), and a physical
> > burden to have to continually open external files (and typing a
> > potentially long path for them) rather than just "bookmark, jump to
> > end of function, navigate unittest blocks" in the same file.
> 
> There are pluses and minuses to both approaches, but I don't think
> that a separate file approach is as difficult as you are suggesting.
> The naming is typically identical to the project entities being
> tested,  with a prefix like "Test_" tacked onto the front of the
> project, modules, classes and functions, making finding things
> straightforward.

Well, in my case it wasn't so simple, because it's an external
testsuite. Meaning the mapping of tests to function names is
non-trivial, because you have to go through the interface language in
order to get at the function at all.


> And most modern editors/IDEs will allow multiple files and projects to
> be open at the same time, allowing test code to be opened only once
> per coding session.
[...]

Being able to open multiple files or not, isn't the problem. (An editor
that couldn't do that would be worthless as a coding editor!)  The
problem lies in having to open multiple files in the first place, for
what's essentially the same piece of functionality.  When I'm working
with a large project, I already have enough files open to
cross-reference stuff that depends on each other.  Having to open yet
another file just to work with the tests is an additional, and IMO
unnecessary, burden.  Even if your IDE can open 50 files at the same
time, you still end up having to scroll through the list of 50 open
files in order to find the one you're looking for -- which is not much
different from having to open a new window and opening a
currently-unopened file.

Whereas if the unittest is already right there *in the current file*,
and better yet, *right next* to the function you're writing, you can
just go to it immediately.  No additional fuss of typing filenames or
navigating big lists of open files (and locating, within said additional
file, the right place where the test is found).

Now of course, a sufficiently-powerful editor like Vim could let you
define macros for automatically finding and opening the test file
corresponding with your current location, and finding the unittest
defined therein for you.  But still, it begs the question of why bother
with such encumbrances when it's really not necessary in the first
place?


T

-- 
When solving a problem, take care that you do not become part of the problem.


More information about the Digitalmars-d-announce mailing list