Stop the Presses: Model-Driven Testing

As we were finishing up this ICONIX+TDD chapter, a couple of new ideas occurred to us, which we decided to publish here at the eleventh hour as an extension to ICONIX Process (and a core part of Agile ICONIX), to link our models more closely to testing, and in fact to drive a testing effort from our use case–driven models. We’ve always thought that testing was a good thing, and that there was great potential to drive tests from use cases. For a different approach to the testing problem, see Jeff Kantor’s November 2001 article titled “Use Case Driven Testing,” which is available from www.iconixsw.com/Articles/Articles.html.

The approach we present here drives the identification of test cases directly from the robustness diagram, in a parallel manner to the way we drive the creation of a skeleton sequence diagram from a robustness diagram. In short, the nouns (Entity and Boundary objects) from the robustness diagram become object instances on the sequence diagram, and the verbs (controllers) get test cases created for them. Figure 12-10 shows the overall concept.

image from book
Figure 12-10: Overview of model-driven testing

As Figure 12-10 shows, we can automatically transform a robustness diagram into both a skeleton sequence diagram and a test case diagram using a simple script. Tests can subsequently be exported to unit testing frameworks like JUnit or NUnit.

Now we’ll provide a more detailed explanation, which we’ll illustrate step by step with an example. Since we’ve already identified the logical functions within a use case as controllers, it seemed natural that all of these functions would need to be tested. Figure 12-4 shows our robustness diagram. Working from this robustness diagram, we can create a test case diagram showing a test case for each controller.

How do we do this? Easy. We copy all of the controllers from the robustness diagram onto a new diagram, and then we link a test case to each one using <<realize>> connectors. Note that the EA tool has a test case element that is a stereotyped use case. Figure 12-11 shows our test case diagram.

image from book
Figure 12-11: Test case diagram for the example shown earlier in this chapter

Note that each test case can contain multiple test scenarios, as illustrated in Figure 12-12.

image from book
Figure 12-12: EA test case spec dialog set to the Scenario tab, with a short test description visible

So, not only can we drive design (sequence diagrams) from the robustness diagram—we can drive the testing effort as well. At the time of this writing, we’re exploring the possibilities of generating unit test code directly from the test case specifications.

As we were formalizing this approach, it further dawned on us that this whole process is scriptable in a visual modeling tool like EA. So, we went ahead and built the script. You can see a fragment of the Visual Basic code in Figure 12-13.

image from book
Figure 12-13: Script fragment screenshot

This script is available in Doug’s multimedia tutorial, “Enterprise Architect for Power Users” (more information is available at www.iconixsw.com).



Agile Development with ICONIX Process. People, Process, and Pragmatism
Agile Development with ICONIX Process: People, Process, and Pragmatism
ISBN: 1590594649
EAN: 2147483647
Year: 2005
Pages: 97

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net