This Article 
   
 Share 
   
 Bibliographic References 
   
 Add to: 
 
Digg
Furl
Spurl
Blink
Simpy
Google
Del.icio.us
Y!MyWeb
 
 Search 
   
Mock Objects
May/June 2002 (vol. 19 no. 3)
pp. 22-24

One thing that makes unit-testing code so hard is the way the real world keeps intruding. If all we had to do was code up tests for methods that sort arrays or generate Fibonacci series, life would be easy. But in the real world we have to test code that uses data-bases, communications devices, user inter-faces, and external applications. have to interface to devices that aren?t yetavailable or simulate network errors that are impossible to generate locally. This all conspires to stop our unit tests from being neat, self-contained (and orthogonal) chunks of code. Instead, if we?re not careful, we find ourselves writing tests that end up initializing nearly every system component just to give the tests enough context to run. Not only is this time consuming, it also introduces a ridiculous amount of coupling into the testing process: someone changes an interfaceor a database table, and suddenly the setup code for your poor little unit test dies mysteriously. Even the best-intentioned developers become discouraged after this happens a few times. Eventually, testing starts to drop off, and we all know where that leads.

Citation:
Dave Thomas, Andy Hunte, "Mock Objects," IEEE Software, vol. 19, no. 3, pp. 22-24, May-June 2002, doi:10.1109/MS.2002.1003449
Usage of this product signifies your acceptance of the Terms of Use.