On 24/03/11 15:19, Jonathan M Davis wrote:
Regarding unit tests - I have never been a fan of putting unit test code
into the modules being tested because:
* Doing so introduces stacks of unnecessary imports, and bloats the module.
* Executing the unittests happens during execution rather than during
the build.
All unittests (as in the keyword) seem to have going for them is to be
an aid to documentation.
What I do instead is put unit tests into separate modules, and use a
custom build system that compiles, links AND executes the unit test
modules (when out of date of course). The build fails if a test does not
pass.
The separation of the test from the code under test has plenty of
advantages and no down-side that I can see - assuming you use a build
system that understands the idea. Some of the advantages are:
* No code-bloat or unnecessary imports.
* Much easier to manage inter-module dependencies.
* The tests can be fairly elaborate, and can serve as well-documented
examples of how to use the code under test.
* Since they only execute during the build, and even then only when out
of date, they can afford to be more complete tests (ie use plenty of cpu
time)
* If the code builds, you know all the unit tests pass. No need for a
special unittest build and manual running of assorted programs to see if
the tests pass.
* No need for special builds with -unittest turned on.
Obviously, it wouldn't resolve all of your concerns, but I would point out
that you can use version(unittest) to enclose stuff that's only supposed to be
in the unit tests build. And that includes using version(unittest) on imports,
avoiding having to import stuff which is only needed for unit tests during
normal builds.
- Jonathan M Davis
That is a good point, but as you say, it doesn't address all the concerns.
I would be interested to hear some success stories for the
unittest-keyword approach. So far I can't see any up-side.
--
Graham St Jack
