Le 08/06/2011 22:01, Darren New nous fit lire :
> Every work on unit testing I've read basically says you should run all
> the unit tests after each change, or certainly at least before each
> check-in.
> 
> However, those same texts say that unit testing should only test
> individual units, and everything else should be mocked.
> 
> Why would I want to run the unit tests for the XML parser after making
> changes to the color picker dialog box?  Or, more generally, why would I
> want to run unit tests that are only executing code that hasn't changed
> since last time the unit tests passed?
> 
> (Note I'm talking specifically of unit tests, not automated test suites
> in general.)
> 

If you had designed your software in blocks, you would have as many unit
test blocks, on a 1 for 1 ratio.
And only the integration phase would know about the dependencies of
blocks and how to arrange them.
When they talk about running again the unit tests, it is only for the
updated block(s), not the whole set.

*BUT*

The main issue is that to perform correctly, if a block X relies on the
blocks A, B & C, the unit tests for X would need replacement plug-ins
for A, B & C (which would emulate the expected behaviour).
Because it might be cheaper to use directly A, B & C, you end up with a
contaminated system: when updating block B, you now have to also run the
unit test for X.
And because the architecture sucks about documentation and enforced
isolation (you can never be sure... unless you are using a fascist
language in its most fascist mode, like C++ without "using namespace
std" and other restriction (no global, no singleton resources...)... or
Ada... but certainly not Java or php or perl (or VB)), it is simpler
(dumber) to rerun all the unit tests of all blocks.

It's all in the budget: aeroplane industries required the plug-ins for
tests (and made specifications for even testing the plug-ins!)... it has
an expensive initial cost. But it allows to test each element and
subsystems in a simulator... software industries goes often the
house-builder ways: fast, cheap to produce, will fix later if caught.
(and when you only have a hammer, everything looks like a nail). Using
army of monkey coders, the usual way is to require to run the whole set
of unit tests (using brute force instead of undocumented (and unchecked)
dependencies' graph). They even make tools to automate that.
(with the same quality!)

Post a reply to this message