On 6/8/2011 13:27, Le_Forgeron wrote:
> When they talk about running again the unit tests, it is only for the
> updated block(s), not the whole set.

I have never seen that recommendation. It's begrudingly accepted as perhaps 
necessary if your unit tests take too long to run.

> *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).

Yep.  The real problem with *this* is that you might update A and its tests, 
then run its unit tests and all goes well, and not realize you had broken X. 
  It never really seemed a good idea to me to be mocking stuff that's 
closely integrated without proper API documentation.

(I.e., mocking the config system that tells you where to load the XSD from 
when testing your XML parser would seem to be reasonable, given that the 
config system is probably well-isolated. Mocking the compiler's lexer while 
testing the parser or mocking the parser while testing the code generator 
never seemed to make much sense to me.)

> 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.

Then that's integration testing.

> And because the architecture sucks about documentation and enforced
> isolation (you can never be sure...

OK. So basically it's "run all the unit tests because there might be 
integration tests in with the unit tests."

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message