Le 09/06/2011 17:11, Darren New a écrit :
> 
> No. But I've seen recommendations that one mocks everything *because*
> that makes the unit testing fast enough to test everything every time,
> as if this gave a clear benefit over just testing what you changed.

Well, the real issue with unit tests is: does the specification know
what to test ? really ?

Most unit tests are just "I checked that 3+3 still gives 6". Which is
only a basic test of nominal functionality. They usually fail on the
coverage of real unit test, due to lack of specification of all possible
issues.

For instance, in Java, you can redefine the value of 3 and 6. Which
means that if your patch keep the 3+3 -> 6, even if now 3 has a value of
14 and 6 has the value of 28, the unit tests would still be ok.

Would have the unit tests checked for some other intrinsics properties
of the module, it might have failed.

And to make matter worst: module often ends up at the top of a huge
pyramid of other modules (at best, when there is at least an ordering),
so emulating the other lower modules is only practical for the very few
lower modules at the base. The higher you go, the more expansive it
became to emulate at the specification time (which is also the time
where you should specify the tests) the interface needed to performed
isolated unit tests.
So they ends with a brute force approach.

-- 
A good Manager will take you
through the forest, no mater what.
A Leader will take time to climb on a
Tree and say 'This is the wrong forest'.

Post a reply to this message