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

test their functionality locally, refactor, and verify—only then committing their changes (frequently, at least daily) to the source code repository. The continuous integration server includes functionality that detects that code has changed, checks out the code, and then builds and tests the entire application in a clean environment, eliminating the vagaries of individual developer’s environments. If the build or tests fail, developers are notified immediately, when they are most able to easily and quickly fix the problem they introduced. That’s the process, simplified. For large applications, we often need to set up a staged build process, which lets us reduce the time needed to build and test (testing is usually what takes the most time). Continuous integration processes go beyond simply ensuring that the automating build compiles cleanly Extending Continuous Integration The automated testing currently done in continuous integration environments is along the lines of functional or unit tests; that is, they verify that the application seems to do what is intended. Can you extend this testing to verify that the application seems to conform to performance, memory usage, integration, and scalability forecasts? It turns out that you can—I call the resulting process “continuous performance management.” Continuous performance management implements performance and scalability testing within a continuous integration environment. The idea is to configure what Fowler calls “secondary continuous integration builds” to execute performance unit tests, integration tests, or load (stress) tests. This lets you, for example, profile the application’s unit tests to identify slow algorithms, incorrect memory usage (such as loitering objects and object cycling), and measure code coverage of tests. You can also test beyond the component level, such as testing integration of components into a working solution by tracing a request as it passes between multiple Java Virtual Machines (JVMs). You can even run automated load tests within the continuous integration test harness to baseline and track the application’s scalability during development. The first prerequisite is having unit tests for your code developed and implemented in a scriptable framework such as JUnit (www.junit.org). This covers component-level unit-test analysis. Integration and load testing requires a different test bed because these are more like business use cases rather than functional tests— the HttpUnit extension of JUnit works well here. To take fullest advantage of continuous performance management, you also need scriptable performance analysis tools; for example, a Java code profiler and memory debugger. That is, you need an engine that will run the performance, integration, or scalability tests, and capture the results. After downloading and installing the Windows version, the first step is to check out a copy of the application’s source code to the project’s directory on the continuous integration server. The following checks out the “trunk” branch of my “tddci” Subversion repository, which I’ve set up for this exercise with a single project named “ant-junit”: svn checkout file:///c:/lib/ svn-win32-1.4.3/repositories/tddci/trunk CruiseControl’s central config.xml configuration file specifies the details of the projects it is responsible for building. Listing One is the initial CruiseControl project definition for continuous integration of our ant-junit project. There are several important CruiseControl components in Listing One. The svnbootstrapper bootstrapper plug-in checks for (and checks out if it exists) new code in the Subversion repository. The schedule section controls how often the source repository is checked for new code, and the Ant task to run (30 minutes is actually a more realistic interval for large projects). The publishers section controls what happens after the CruiseControl project has completed its run—in this case copying the newly built JAR file to an artifacts directory if successful, and sending notifications in any case. With this project defined, you can start CruiseControl by running its cruisecontrol.bat (or cruisecontrol.sh) file. Figure 1 shows its Setting up Continuous Integration So let’s look at a real working continuous integration environment that has been extended to performance testing, the one I use daily in my work. There are various continuous integration servers available, but for this exercise I chose CruiseControl (cruisecontrol.sourceforge.net). Figure 1: Test results page in CruiseControl web console. March 2008 l www.ddj.com l Dr. Dobb’s Journal 37 http://www.junit.org http://cruisecontrol.sourceforge.net 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.