I recently read a short book called “Continuous Testing.” The authors present the case that we should focus on assessing the business risk in our software, and make continuous real-time decisions about the tradeoffs involved in improving software quality.
More about that in a moment, but first, let’s talk about the whole “Continuous” meme.
Remember when we did software builds? We ran the compiler and linker manually. Then we automated our build process. When we first started talking about agile methodologies like Extreme Programming (XP) and Scrum, we accelerated the timelines, so nightly builds became the norm. Soon even that was too slow, and Continuous Integration appeared.
In the words of Martin Fowler’s seminal essay, “Continuous Integration,” written in September 2000:
We are using the term Continuous Integration, a term used as one of the practices of XP (Extreme Programming). However we recognize that the practice has been around for a long time and is used by plenty of folks that would never consider XP for their work. We’ve been using XP as a touchstone in our software development process and that influences a lot of our terminology and practices. However you can use continuous integration without using any other parts of XP—indeed we think it’s an essential part of any competent software development activity.
There are several parts to making an automated daily build work.
• Keep a single place where all the source code lives and where anyone can obtain the current sources from (and previous versions)
• Automate the build process so that anyone can use a single command to build the system from the sources
• Automate the testing so that you can run a good suite of tests on the system at any time with a single command
• Make sure anyone can get a current executable which you are confident is the best executable so far.
The principles of Continuous Integration haven’t changed much in the past 14 years, though of course methodologies have evolved, build and CI tools have become incredibly sophisticated, and test automation has become core. Indeed, some agile methodologies, like TDD, place testing at the center of the universe. As Scott Ambler writes in “An Introduction to Test Driven Development (TDD)”:
Instead of writing functional code first and then your testing code as an afterthought, if you write it at all, you instead write your test code before your functional code. Furthermore, you do so in very small steps—one test and a small bit of corresponding functional code at a time. A programmer taking a TDD approach refuses to write a new function until there is first a test that fails because that function isn’t present. In fact, they refuse to add even a single line of code until a test exists for it. Once the test is in place they then do the work required to ensure that the test suite now passes (your new code may break several existing tests as well as the new one). This sounds simple in principle, but when you are first learning to take a TDD approach it proves require great discipline because it is easy to “slip” and write functional code without first writing a new test.