What is the relationship between "integration testing", "continuous integration servers" and "nightly builds"?

Question

I've been out of school for a few years now, and just recently started going back and re-reading some of my textbooks (I want to stay fresh). I've actually found my software engineering textbook fascinating and plan on reading the whole thing - which if funny, because when I was in school I found it horrifically boring.

So there's a half-chapter dedicated to integration testing. And, like most things in academia, it's all theory with very little practical applicability anywhere in the reading. But, it got me thinking.

We use CruiseControl for continuous integration testing, but seeing that we are a large development team and I don't handle deployments/builds/releases, I've never worked with it hands-on. I just get an email every now and again when I break the nightly build. And two tech leads to explain myself to.

Getting on to my question: my old textbook refers to integration testing as the pairing and testing of components with each other, as opposed to unit tests which target 1 particular class. This can be done in a "top-down" or "bottom-up" approach, where top-down implies testing the whole things as a system, and then recursively breaking down the system into smaller subystems and testing them; bottom-up implies the opposite (start small, grow big).

My question:

How do the following threee concepts relate to each other:

• This academic explanation of integration testing; and
• So-called "continuous integration servers" like Hudson, Jenkins or CruiseControl; and
• The concept of having a "Nightly Build" where code is checked out of a SCM and compiled automatically

Is it just coincidence that the first two have the word "integration" in them? Is performing a "nightly build" the same as running a continuous integration server (at night), or are they two separate concepts?

And if continuous integration testing & nightly building have absolutely nothing to do with academic integration testing, then how does integration testing actually manifest itself in the real world? Are their frameworks like JUnit out their but that only concentrate on integration testing?

I know these are a lot of questions, but they really just boil down to understanding what each of these are and how they are used. Online searches for each of these pull back pretty vague, abstract answers.

Answer 1

Too vast to explain in few lines.

Continuous integration is basically the cycle for automated checkouts, build, tests, code quality checks, deploy and much more. The tests part of it would include the Unit testing (unit code), integration testing (with dependecies on database or external resources) with tools and frameworks like junit, rspec.

These can be scheduled for nightly builds and build on regular intervals.

Continous integration tools like cruisecontrol, hudson help you to configure this process. Its more like a schedular to do different task, define dependencies with addition to notifications and artifact management and much more.

All of these are pretty much interdependent.

More info @ http://martinfowler.com/articles/continuousIntegration.html

Answer 2

"Integration testing" is used in several ways; the use of the word "integration" in "integration testing" and "continuous integration" is due to a meaning of "integration testing" that was more common in the past.

• "Integration testing" generally refers to tests that test all of one's code at once, or at least several pieces of one's code at once. It is the complement of "unit tests", which test a single module of one's code at a time. In most projects unit and integration tests run in the same test suite. In large projects, especially in the past when the software industry wasn't as good at automating tests, integration tests might be done in a separate process, on a system assembled from the work of different teams. The "integration" in "continuous integration" came from this latter usage.

• "Continuous integration" is the practice of running your project's build every time the source code changes. "Build" includes compiling (if your language needs compiling), generating artifacts to deploy, and running automated tests (including unit and integration tests). Continous integration servers support this process by watching the source code, starting the build and reporting the results.

• "Nightly build" is the practice of running your project's build overnight. It has been replaced in most cases by continuous integration, because it's better to know your build is broken as soon as possible.