Channels ▼
RSS

Testing

Unit Testing Without Mocking Makes a Mockery


Unit testing company Typemock Ltd. points to new research into Agile software application development practices calling for a deeper level of granularity into extended code analysis in the pursuit of better debugging. The company highlights findings which estimate that 70% of Agile developers say that they unit test, but says that much less of them really write automated, isolated unit tests.

Since isolation requires "mocking", developers are not testing their software as thoroughly as they might, says Typemock product manager Gil Zilberfeld, who asserts that mocking paves the way to:

  1. Running tests faster
  2. Debugging tests faster
  3. Writing tests faster
  4. Covering edge cases

"When your unit tests use mocks, they run faster. Instead of expensive calls to the database or the cloud, you can shorten tests to milliseconds. A full test suite can run in seconds instead of hours, giving you immediate feedback on your code," says Zilberfeld.

Typemock says that by using its methodologies and technologies when a unit test fails, you don't need to start up the entire application, set a breakpoint, miss it, return to it, shut it down, fix it, and repeat until it's really fixed — as unit tests (typically) test very small pieces of code, where the rest is mocked.

"Suppose you had a thousand tests, each requiring a special database setup — and you'll need to clean up after every scenario. How much time would you spend on just these steps? Setting up mocks is way easier and much more effective. Finally, what about those edge cases, where you actually need to shut down the Internet? Instead of cutting real power cords, use a mock instead. Tests give reliable results, plus, the rest of us can keep using Wikipedia," says Zilberfeld.

So if we accept the assertion that mocking is really what makes unit tests work, our code should and could be easier to maintain as a result.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video