Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Tools

Better, Stronger, Faster Integration Testing


Andrew and Jennifer are the authors of Applied Software Project Management (O'Reilly & Associates). They can be contacted at www.stellman-greene.com.

We can all agree that integration testing is important. But it's not fun. Yes, programmers need to make sure that the software they deliver works. It's all too common to send a build off to users or testers, only to have it immediately back bounce with serious problems. We all recognize that sinking feeling when we've realized that we're in for a long night of tracking down bugs and patching code. And there's nothing more deflating than thinking that you've built a great piece of software, only to get nothing but negative feedback. So we, as programmers, bite the bullet and run our integration tests. But even when they're effective, they can be monotonous.

Typically, the goal of integration testing is to prove that all of the features have been developed, and that they work together well enough for the project to be delivered. For some projects, that delivery may be to a customer or user. In others, the software is delivered to a testing team for functional, system, and regression tests. On an iterative or Agile project, integration tests happen at the end of each iteration. But in all cases, developers need to convince themselves and others that the software really works before they feel comfortable releasing it.

Every project you've ever worked on with more than one developer has done some sort of integration testing. The software is broken up into pieces, each of which is developed by individual programmers. When programmers feel that their work is done, they integrates it with the rest of the product and make sure that it "plays nice" with the rest of the software. This is done in a variety of ways. On some projects, it's unplanned and ad-hoc; developers just play with the software in ways that they think it might break. In more structured environments, a QA team defines a set of tests that exercise the core behavior across multiple features based on integrated code, then pass those tests on to developers to be run. The tests must pass before the QA team accepts the build. But in all cases, developers are left with a task that's relatively unrewarding, time-consuming and not intellectually engaging.

"We can rebuild..."

One reason many programmers view integration testing as a "necessary evil" of software development is that the interesting work is usually finished before integration tests begin. The architecture decisions have been made and implemented, and the only changes made to the code are done to fix minute details. Often, programmers delegate integration testing tasks to junior team members, who end up mindlessly running a subset of the QA team's test cases. It's not uncommon to draft testers for this task as well. Everyone finishes their piece, then moves to something else, until someone throws a bug back to them.

It doesn't have to be this way. Instead of looking at these tests as a final obstacle before the handoff, the team can view integration testing as an opportunity to take a step back and get a good sense of what they've built. The team can cap off a project by bringing everyone together to figure out how to put it through its paces. If done right, integration testing can actually be interesting, and even a morale booster. Building a house of cards is fun, but kicking it down even more so! And if team members uncovers a serious problem, they can all share in the sense of relief that they got to it first, before anyone else found out about it.

A good integration test takes advantage of the fact that the programmers have intimate knowledge of the code. When the team has just finished writing the code for the project, they know more about it than anyone else at any other time. If you've just spent months building a piece of software, you know where the stitches are. You know how it breaks down into pieces, and you have a better idea than anyone else about what might break it. Integration testing is your chance to prove how good your solution really is. If you treat it that way, then you and the entire team can get behind the product--and deal with any major problems then and there, while the memory of its construction is still fresh.


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.