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

Core Technology CHANGE CODE WITHOUT FEAR functional test cases for every piece of code as developed. Automated test cases are invaluable for quickly generating a baseline test suite to help you identify whether code modifications change code behavior. However, they may need to be extended to verify the continued operation of use cases, check scenarios that require a complicated setup, or simply improve test coverage. This requires injecting human intelligence into the automatically generated test suite. One way to extend the test suite is to enhance the automatically generated test cases (that is, by adding more function calls, using more realistic inputs, ensuring that objects are properly initialized, and so on). Another way is to write your own functional tests using whatever test frameworks are applicable for your application (JUnit, Cactus, CppUnit, NUnit, and the like). If the team has any legacy test cases (for example, unit test cases that developers wrote for onetime verification), those should also be integrated into the test suite. Additionally, leverage any other technologies you have at your disposal to generate test cases that cover vital functionality and/or provide increased coverage of your application. These tests should all be executed in concert with the automatically generated test cases, letting you see the cumulative coverage of the complete test suite. For example, if you are working on a web application and/or SOA, tests that exercise the application from those perspectives should also be added. Ideally, such tests should be converted to source-code level tests (such as JUnit or HTTPUnit). This correlates front-end and message-layer behavior to the back-end code, which helps you: • Isolate the code responsible for any issues discovered in the Web or SOA test scenarios. • Determine how much of your code is exercised by your complete test suite. Pattern-matching and data-flow static analysis are also valuable extensions to the regression test suite. Traditionally, people do not consider static analysis as part of the regression test suite, but it can be a very important tool in detecting regressions. Tools that can run pattern-based and data-flow static analysis are good at identifying mechanical errors that would take humans a long time to find. Think of it this way: This morning, no violations were reported for your code. You change the code today, then when you arrive at work tomorrow morning, you see a violation reported for that code, alerting you to a coding problem that—if not corrected—causes resource leaks. This is essentially a regression failure—it indicates that the recent code modifications introduced problems into the code. If static analysis was not performed as part of the regression testing, this problem might have gone unnoticed until load testing later in the development process, when it would be considerably more difficult to diagnose and repair. Establishing a Supporting Infrastructure Running automated and regularly scheduled build and testing processes should involve minimal distraction if set up properly and if all required infrastructure is present. At minimum, that infrastructure should include a source-control system, a tool for automated test execution, and a reporting mechanism to track results of the automated build and testing. Most development teams use a sourcecontrol system to store code they are working on. Some teams store their tests in the source-control system, and others leave testing to the discretion of the individual developers. In some cases, developers are testing the code on their own machines, but the tests never make it into the source-control system. In other cases, they do some testing if time permits and don’t do any when in a crunch. In either case, the value of any tests that exist on an individual developer’s machine is minimal and such tests are typically used only to verify that the code is functioning properly at the time it is written. Once stored into the source-control system, the test can be leveraged over and over to validate that the new code didn’t break the existing functionality or introduce problems that could impact reliability or functionality. The regression suite generation/execution should be scheduled to run regularly (for example, nightly, or several times a day in a continuous integration process) in whatever manner makes the most sense for your specific development environment and team. This could be a combination of an Ant script and Windows scheduler or CruiseControl, or a shell script and a Listing One /** * Test for method: initOrder(com.ibatis.jpetstore.domain.Account,com.ibatis.jpetstore.domain.Cart) */ public void testInitOrder21() throws Throwable { Order testedObject = new Order(); Account account = new Account(); Cart cart = new Cart(); account.setUsername("username1"); account.setPassword("password0"); account.setEmail("email0"); account.setFirstName("firstName0"); account.setLastName("lastName0"); account.setStatus("status1"); account.setAddress1("140 East 45th Street, New York, NY 10017"); account.setAddress2("1600 Pennsylvania Avenue NW, Washington, DC 20500"); account.setCity("Tokyo"); account.setState("New York"); account.setZip("90011-1234"); account.setCountry("England"); account.setPhone("1234567"); account.setFavouriteCategoryId("favouriteCategoryId0"); account.setLanguagePreference("languagePreference0"); account.setListOption(false); account.setBannerOption(false); account.setBannerName("bannerName0"); testedObject.initOrder(account, cart); assertNotNull(testedObject.getLineItems()); assertEquals(0, testedObject.getLineItems().size()); assertNotNull(testedObject.getOrderDate()); assertEquals(new java.util.Date().toString(), testedObject.getOrderDate().toString()); assertNotNull(testedObject.getTotalPrice()); assertEquals("0", testedObject.getTotalPrice().toString()); assertEquals("P", testedObject.getStatus()); assertEquals(0, testedObject.getOrderId()); assertEquals("username1", testedObject.getUsername()); assertEquals("140 East 45th Street, New York, NY 10017", testedObject.getShipAddress1()); assertEquals("1600 Pennsylvania Avenue NW, Washington, DC 20500",testedObject.getShipAddress2()); assertNotNull(cart.getAllCartItems()); assertNotNull(cart.getCartItems()); } 30 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.