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

Core Technology by Nada daVeiga Change Code Without Fear Utilize a regression safety net Working on an existing code base that has minimal or no tests is like walking on eggshells: Every Nada is Product Manager of Java Solutions at Parasoft. She holds a bachelor’s degree in computer science from the University of California, Los Angeles and can be contacted at ndaveiga@parasoft.com. move you make has the potential to break something. Yet when you’re working on software, the damage is not always immediately obvious—at least, not without extensive, system-wide testing. But such validation is not always possible or easy, considering the frequency of change, limited resources, and looming deadlines that most developers face. As a result, many developers commit their additions and modifications, then cross their fingers and hope for the best. If your code lacks sufficient tests, Behavioral Regression Testing is a technique that provides a fast and easy way to determine if code modifications change or break existing functionality. What is Behavioral Regression Testing? It’s a baseline test that captures the project code’s current functionality. To detect changes from this baseline, you run your evolving code base against a test suite on a regular basis. In most cases, such a test suite can be generated overnight using automated unit-testing tools. Once this test suite is in place, you can incrementally improve its intelligence and value by adding more test cases, modifying the automatically generated ones, and keeping it in sync with intentional program changes. The resulting test suite serves as a changedetection safety net, letting you modify code without fear of accidentally changing or breaking the code’s intended behavior. The key to making this practice practical is to automate as many tasks as possible so that you can focus your efforts on the few regression-testing tasks that truly require human intelligence. By leveraging automation for this purpose, you gain a reliable way to determine when and how your code modifications impact the rest of the application—with minimal effort. In this article, I explain how to build, maintain, and extend Behavioral Regression Test Suites that help you write code faster and change it with confidence. • Phase 1. Automated one-time test generation. A one-time process that involves generating a regression test suite that can be run on a regular basis and will not report any errors unless the captured behavior changes (Figure 1). • Phase 2. Automated test generation for new code + Automated daily execution + extend tests. A daily process that involves automated generation of regression tests for new code, as well as automated execution of the existing test suite. After the execution completes, you review and respond to any functional changes that the test suite detected. The response process involves injecting human intelligence into the test suite. Once per project, an automated unit test generation tool scans the project code base (accessed from the source control system), then automatically generates and executes unit test cases with assertions that capture the project code’s current functionality for a wide range of automatically generated test scenarios. Test execution results should be stored on a central server, where they can be shared team-wide, and the generated tests should be added to source control. At this point, you might want to fine-tune the test suite to minimize noise (by ignoring any assertions that fail on a second run against the exact same code base, ignoring time-sensitive and date-sensitive assertions, and so forth). However, such fine-tuning is completely optional at this phase. Because your goal is to establish a behavioral baseline rather than verify the application’s current functionality, there is no need to actually review—or even glance at—the generated tests or the assertions/observations/outcomes attained. Assuming that your application is currently functioning as expected, just Understanding the Key Phases There are two key phases involved in creating and using Behavioral Regression Test Suites: 28 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.