Integration testing has been with us for many years, but it still is something of a nether region. How a service...
interacts with another service and with underlying objects and functions deeper in the software stack often remains a mystery. On one level, the problem resembles the tyranny of numbers problem faced by computer scientist before the advent of the integrated circuit. At the time, the mass of wires connecting modules was becoming an unmanageable problem.
The issue of integration testing may come to take precedence over unit testing, if we are to believe Walker Royce, Chief Software Economist, IBM Rational. Speaking at last week's Innovate 2011 event in Orlando, Fla., Walker suggested that much re-work and much gear gnashing occurs when unit testing takes precedence over integration testing.
Unit testing is important, surely, and it is one of the most characteristic traits of the successful agile project. But it is not an end in itself. Thorough unit testing is expensive, taking up precious time. Software architects should arrive at some sense of how modules will integrate – even whether they are needed at all – well before an exhaustive unit test regime occurs, according to Royce.
"We are reaching the limits of individual productivity improvements,'' he said. "If you really want to make the transition from conventional governance to modern economical governance, integration testing should precede unit testing. ''
Integration is important in other ways too. Take, for example, the integration of development and operations efforts. In the fast paced enterprise of today, it is not acceptable to have a lag because development's product doesn't readily map onto operation's machines. At Innovate we caught up with Agile evangelist Scott Ambler, who told us IBM had been working on a framework for better integrating development and operations – ''DevOps,'' if you will. Read about Disciplined Agile Delivery (DAD) on the SOATalk Blog.