Better Software - December 2007 - (Page 37)

also exercises all of these built-in assertions that look for additional invariants that derive indirectly from the requirements. The developers thought that it would be a good idea to leave the assertions in the code in the field, either to drive recovery action or to print out a message that the customer should contact customer service to report a bug. But the boss was uncomfortable with this and told the developers not to do it. We don’t want our code failing in the field; it should continue to run. Even when admonished that continued operation in light of a failed invariant renders the program’s results invalid and that it would be better to stop the program than to silently corrupt the client data, the boss stood his ground. The overtaking company’s management discovered his reaction and re-assigned him to staff a telephone in customer service. Exhaustive testing is impossible, and you cannot test quality into a product. Forward-engineered spot checks do not constitute adequate testing; in fact, their value is very low. Instead: • Use invariants and assertions that formally tie to the user needs as they are understood. While total formal program proving is a long way off, it is better to get the broader coverage that invariants and assertions can give you than to use the spot-checking of a unit test. • Don’t forget code inspections—one of the most cost-effective bug-spotting techniques we’ve got. • As noted by Laurie Williams, if you’re pairing, you already have four eyes looking at every line of code, and that will help your quality immensely. Change pairings frequently so you don’t get into mind-lock with each other. And remember that even pair programming is no substitute for good design. We know that this story has been about TDD and that TDD is not a testing method, but a design method—that it is the main testing focus on many projects to the contrary notwithstanding. But just in case you were interested in testing . . . improved usability in the final product. Gertrud has published Patterns for the Role of Use Cases, and she is a founder of the Danish Agile User Group. Email Gertrud at gertrud@gertrudandcope.com. Jim Coplien (http://users.rcn.com/jcoplien) has been a software professional for more than thirty years and is currently senior agile coach and systems architect at Nordija A/S in Copenhagen, Denmark. He is author of pioneering software design books including Advanced C++, Multiparadigm Design, and Organizational Patterns of Agile Software Development. He is a founding member and Member Emeritus of the Hillside Group, the group that launched the software pattern discipline. When he grows up, he wants to be an anthropologist. Email Jim at JOCoplien@cs.com. Neil Harrison is an assistant professor of computer science at Utah Valley State College in Orem, Utah. Before that, Neil developed software professionally for more than twenty years. He is the co-author of Organizational Patterns of Agile Software Development. Neil is acknowledged as the world's leading expert on pattern shepherding. The pattern conference (PLoP) shepherding award is named after him. Email Neil at harrisne@uvsc.edu. The authors thank Stine Laforce, Rex Black, Jeff Sutherland, Håkan Reis, and Magnus Mårtensson for comments, criticisms, and encouragement. Don’t Neglect System Testing Unit testing can help, and tests can play a role in sharpening one’s thinking—but not as most people practice TDD. There is hope. Those who live at the leading edge of the curve with healthy skepticism and long hindsight are offering healthy alternatives. Many of the recommendations from above can be found embodied in behavior-driven development (BDD) as advocated by Dan North. BDD is a more sober and sane approach that integrates testing and development—not as a way to supplant careful structuring, but as an audit on how the system meets end-user needs. We are seeing other sound ideas that return to solid principles of quality-oriented development, such as Bertrand Meyer’s contract-driven development. The kneejerk reactions that took place in response to overly heavyweight interpretation of their principles are extreme but are done absent responsible reasoning. Instead, follow the proven practices as described in these articles. They can be summarized as follows: Testing is an integral part of software development and requires the same careful attention to systematic design as writing the code itself. Just like the code, the tests must be designed; however, test design is essentially different from code design. One cannot simply augment cowboy coding with cowboy testing and expect to produce a quality product. {end} Gertrud Bjørnvig is an independent consultant focusing on agile software development. During her twenty years in software development, she has been working at Scandinavian companies such as TietoEnator and Navision. As a use case expert, she has worked closely with test specialists and usability specialists to find a common ground in use cases that can support improved quality as well as www.StickyMinds.com Sticky Notes For more on the following topics go to www.StickyMinds.com/bettersoftware. I I References Kent Beck DECEMBER 2007 BETTER SOFTWARE 37 http://users.rcn.com/jcoplien http://www.StickyMinds.com/bettersoftware http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - December 2007

Better Software - December 2007 Contents Mark Your Calendar What's Happening @ StickyMinds.com Technically Speaking Code Craft Test Connection Management Chronicles Man and Machine Let Your Values be Your Guide A Story About User Stories and Test-driven Development Product Announcements The Last Word Ad Index

Better Software - December 2007

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.