Continuous Integration is Absurd without Unit Testing


Continuous integration is absurd without unit testing. Imagine this conversation between colleagues:

“We are DevOps pioneers,” my colleague says, swinging his arm towards the Dell Inspiron that hums away on the edge of his desk. On the screen, a mass of red boxes blinks into life whilst a cartoon man, grinning in a bowtie, watches on from the top left. 

“Nice. What does it do?” asks Kelly from the test team.

“Checks out our code and builds it…” A pause, I assume for dramatic effect, “…. We are now performing,” he waggles his fingers in an air quotes gesture, “Continuous Integration.”

My eyes roll.

In software engineering, continuous integration (CI) means the repeated application of quality control processes on every small discrete change or addition. It doesn’t mean installing Jenkins on a spare machine.

Continuous integration has many advantages. When tests fail or bugs emerge, developers can revert the system to an earlier, safe state, without wasting time debugging. It is possible to detect and fix integration problems, avoiding last-minute chaos at release dates.

CI testing provides:

  • Instant feedback on broken and incompatible code.
  • Early notification of conflicting changes.
  • Immediate testing of changes.
  • Constant availability of a build for testing, demo, or release purposes.
  • Feedback to developers on the quality, functionality, or system-wide impact of their code.
  • Frequent code check-ins motivate developers to create modular, less complex solutions.

In true agile environments, every piece of code a developer commits to the repository triggers a build cycle. This cycle has quality gates and the build will only progressing with successful results from dynamic testing and analysis tools. This ensures that only clean, functioning code leaves the isolated development branch and reaches the release branch. With this approach, the traditional software development phases become blurred, and everything happens together.

“Why is everything red?” asks Kelly.

“Ah… when we make a code change, the unit tests run. Your team hasn’t delivered updated tests yet and so the old tests always fail against the new code.”

“But how do we deliver working unit tests before they have checked the code in?”


Updated unit tests should accompany every code change. A robust, reliable and easy-to-use desktop development environment, with unit testing capabilities built in, is instrumental to this process. In an ideal set-up, you check in unit tests developed along with updated code. This provides automated regression tests during the CI build stages.

“It’s OK,” says Kelly unfazed, “I’ll just get our guys to work in partnership with the development team, so we can push updated tests at the same time as the code.”

DevOps is a movement driven by the breaking down of silos and adopting continuous integration techniques. It’s an organisational shift that has seen its adopters realise a multitude of business benefits, not just in project performance but also employee satisfaction.

Automated regression testing is at the core of continuous integration. Effective unit testing at every stage in the development creates the vital feedback to enable the team to realise the real benefits of adopting DevOps.