Dr. Dobb's Journal - March 2008 - (Page 36)

Core Technology by Steven Haines Continuous Integration and Performance Testing Extending to include continuous performance management Automation has arguably done more to improve the development lifecycle in recent years than virtually anything else. As applications have become increasingly complex, iterative, and disSteven is the Java EE Domain Expert at Quest Software. He can be contacted at steven.haines@quest.com. tributed, we seek to automate the software development process even further, beyond such mainstream development practices as automated source control and nightly build systems, towards automating integration and testing. Continuous integration is one such “next step,” one that can be extended to also automate certain kinds of testing. In this article, I extend continuous integration systems to perform integration, performance, and load testing. While this discussion uses Java EE and associated tools, the concepts are equally applicable to other platforms. tinually when new code is checked in, or at least several times a day. A continuous integration process requires (paraphrased from Fowler’s paper): • A single code repository. (I use Subversion, but you could use others like CVS, Perforce, and so on.) • Automated build process with self-testing. (I use Apache Ant, you could use Maven.) • Daily code commits. • Continuous integration server that can build, integrate, and test the entire application quickly. • Ability to test in a clone of production environment. • Ability to broadcast overall build status. • Ability to automatically deploy and broadcast availability of builds. Continuous integration processes go beyond simply ensuring that the automating build compiles cleanly. To declare a build to be successful, it must pass basic functional tests. So we do need a somewhat mature development process, where teams all work from the same code repository, write a test case for the functionality they develop, build and Continuous Integration Basics Continuous integration is a software engineering process where an application under development is completely rebuilt and tested frequently and automatically. While not an entirely new concept, the term was coined by Martin Fowler in a paper (martinfowler .com/articles/continuousIntegration.html) and grew in popularity as part of extreme programming (XP) practices and methodologies. Many of us have horror stories of working on large development teams, where we each worked independently on our portions of an application, then spent as long (or longer) integrating all the pieces together into a working application. Part of the appeal of XP is the notion of integrating the application con36 Dr. Dobb’s Journal l www.ddj.com l March 2008 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - March 2008

Dr. Dobb's Journal - March 2008 Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook Social Networks and Software Development Conversations Detecting Bugs in Safety-Critical Code Change Code Without Fear Continuous Integration and Performance Testing Wt: A Web Toolkit Automating Release Notifications The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.