The Community for Technology Leaders
RSS Icon
Subscribe
Issue No.03 - May/June (2002 vol.19)
pp: 22-24
ABSTRACT
<p>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.</p>
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
29 ms
(Ver 2.0)

Marketing Automation Platform Marketing Automation Tool