cc licensed ( BY NC ) flickr photo
shared by Wonderlane
Modern software development often adopts the practice of Continuous Integration (CI). In CI, developers frequently integrate new or altered code into a single source repository to facilitate the detection of defects in the code. This repository takes the form of build servers. As CI wants to use these build servers to rapidly find bugs, the build itself must be fast and self-testing whenever possible, though these automated tests must limit themselves to unit testing during peak times.
Automated unit testing is synonymous with a self-testing build, but only unit testing can be automated. A build that regularly performs automated unit testing will run better code and run more quickly; a quicker build will ease the load on the build servers. Typically, organizations have a finite number of CPUs and a finite amount of RAM to address the common needs of CI, such as multiple simultaneous check-ins and build queues. A non-optimal build will slow down the build server, increasing the time it takes to witness feedback from a check-in or commit. In an environment mandating frequent, regular code integration, this is unacceptable.
Unfortunately, it is not uncommon for engineers to script “unit tests” that do too much or run as a hybrid of other test types. Unit tests must only test a unit of code isolated from its dependencies, or it is not a unit test. They should also require only a simple command to execute. They must be self-checking. Though other types of tests lend themselves to easy automation, they should not be part of the self-testing build because they will bog down the servers during prime work hours. Integration tests, user interface tests, and performance tests, while critical, are best run at night or during other slow times such as the weekend. While unit testing alone will not catch each and every bug, it will catch more than enough to justify its application and forms the first line of defense against buggy code.
Fast build servers require clean, relatively bug-free builds, so much so that one should write the automated unit tests before writing the actual code. It is advisable to think of the test scripting not only as a code evaluation tool, but as a means to become intimate with the system’s design.
Continuous Integration requires constant feedback and fast builds via collaboration onto build servers; these servers can run automated unit tests to facilitate both. Other, more rigorous testing should be reserved for hours of low usage so as not to affect the hour-to-hour running of a CI development team.
For more information about software quality assurance and testing, visit Magenic who have been one of the leading software development companies providing innovative custom software development to meet unique business challenges for some of the most recognized companies and organizations in the nation.