Better Software - January 2008 - (Page 66) Figure 2: Detailed test script—Add movie title, reject duplicates Figure 3: Executable example—Add movie title, reject duplicates contains) and validating outcomes (e.g., inventory unchanged). Writing tests with a DSTL is much like building with Lego bricks—simply snap the appropriate pieces together and fill in data related to the particular example. Sophisticated compound pieces are built by snapping smaller pieces together, enabling both functional tests and unit tests to be built from the same DSTL elements. The landmine here is the expectation that tests will take only a minute or two to write—a pace that is sustainable only for simple domains with no precondition set up (like those typically used in demos, training courses, and articles) or if a mature DSTL exists. Without a DSTL, teams head down the “Pay Me Later” path as shown in figure 4. Tests initially are churned out quickly; however, the same test fragment is repeated in many tests. Eventually progress comes to a screeching halt when maintenance is required on the repeated fragments. The alternative path, “Pay As You Go,” which is shown in figure 5, is uncomfortable because progress is much slower early on. Because each DSTL is specific both to the domain and to the system being built, you must build each Lego piece before you can use it. When building tests for the long term, you must accept the paradox: By going slower at first, you will go faster in the long run and will be able to maintain the optimal pace much longer. Figure 4: Pay Me Later Figure 5: Pay As You Go 66 BETTER SOFTWARE JANUARY/FEBRUARY 2008 www.StickyMinds.com 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.