where unittests should be [was: Strategies for resolving cyclic...]

spir denis.spir at gmail.com
Thu Mar 24 04:22:20 PDT 2011


On 03/24/2011 07:44 AM, Jonathan M Davis wrote:
> Personally, I find the unit tests to be _way_ more maintainable when they're
> right next to the code. I _really_ like that aspect of how unit tests are done
> in D. However, it does mean that you have to dig through more code to get at
> the actual function definitions (especially if you're thorough with your unit
> tests),

My position is intermediate between ones of Jonathan and Graham: I want 
unittest to be in the tested module, but cleanly put apart. Typically, one 
module looks like:
1. general tool (imports, tool funcs... systematically present in all modules)
2. specific tools (import, tool funcs & types)
3. proper code of the module
4. tests

Advantages:
* clarity
* what Janathan evokes above: unittests don't clutter code
* tools specific to testing are grouped there
* and the following:

The test section can look like:
* tools (imports, tool funcs, tool types, (possibly random) test data factory)
* a series of "void test*()" funcs
* finally:
unitest {
     testX();
     testY();
     testZ();
     ...
}
void main() {}

 From there, I can control precisely what test(s) will run, according to the 
piece of code I'm currently working on, by simply (un)commenting (out) lines in 
the single unittest section.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



More information about the Digitalmars-d mailing list