Better Software - January 2008 - (Page 68) Figure 7: Full TDD lifecycle another team to upgrade or port the aged legacy system. If the tests have survived thus far, the functional tests are used to test drive the porting work, while the original unit tests are appropriately retired (see the StickyNotes for more on test-driven porting). Like modeling clay, which has a limited shelf life that can be prematurely shortened if left uncovered, much careful planning and handling is required to make sure the automated test suite doesn’t “dry up” part way through. For TDD to be regarded a true success, the functional tests should be considered reliable requirement artifacts, and all of the relevant tests should continue to pass for as long as the system is alive. Supporting the handoffs between teams is a key factor in achieving this level of success. and, at worst, stifle the very creativity and fluidity that the prototyping is being used to facilitate. NEW YEAR’S RESOLUTION I’ve experienced enough Christmasmorning heartbreak firsthand that I’ve resolved to carefully read the fine print when I shop for my daughter’s toys. In recent years, I’ve discovered that the local news station runs a pre-Christmas series on the hottest holiday toys. The toys are arranged in a room, and children are invited in for unstructured play. We observe firsthand which toys the children are drawn to, which ones they actually spend time playing with, how engaged the play is, and what problems they encounter. This reporting from the field is an invaluable source of relevant information for harried parents. I’ve received enough bruises from the TDD “School of Hard Knocks” that I have resolved to make the fine print more visible and relevant. I encourage you to study reports from the field that contain hard-won insights and hands-on experiences from ordinary practitioners. However, I can only go so far: I can lead team members to the fine print, but I can’t make them read it. How have things been going on your TDD projects? Are you using it when you shouldn’t be? Are you practicing it effectively? What will you resolve to do differently to make this a better TDD year? {end} www.StickyMinds.com Jennitta Andrea is a hands-on analyst, developer, tester, retrospective facilitator, coach, and instructor. Her multi-faceted experience on more than a dozen different agile projects since 2000 is reflected in her frequent publications and conference presentations (see www.theandreagroup.ca). Jennitta’s main interest is in improving the state of the art of automated functional testing as it applies to agile requirements (see the StickyNotes for more information); she applies insights from her early experience with compiler technology and domain-specific language design. Jennitta is a board member of the Agile Alliance and is serving on the IEEE Software Advisory Board. She loves golf, ballet, playing games, and spending time with her family: Jim, Ava, Shark Boy, and Lava Girl. FOR CHOKING HAZARD CHILDREN UNDER THREE Just as some toys are not appropriate for all children and could even pose great danger to some, TDD is not suitable for all types of projects. Testing consultant Jonathan Kohl highlights where things can go wrong: TDD isn’t appropriate for quick and dirty prototyping or throwaway exploratory work where the quality of the end product is not a major concern. Applying TDD in cases like these would, at best, be a waste of effort Sticky Notes For more on the following topics go to www.StickyMinds.com/bettersoftware. I I I I I User stories Functional testing Test-driven porting References and further reading Refactoring 68 BETTER SOFTWARE JANUARY/FEBRUARY 2008 http://www.theandreagroup.ca http://www.StickyMinds.com/bettersoftware http://www.StickyMinds.com
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.