Chapter 5. Model-driven development solution life cycle
5.7 Testing
There are numerous on-going projects in the field of model-based and model driven testing.
Model-based testing is an approach to testing that uses a model of a system to predict its behavior and uses the predictions to automate test cases.
Model-driven testing focuses on providing a toolset and a test execution environment to automate the running of tests, and leaves the model developer free to focus on devising a good set of tests specific to the application.
We do not cover model-based testing or the automated generation of test cases here. However, we discuss the model-driven testing approach.
Model-driven testing can be described in two phases:
Testing the model framework
Verify the framework to ensure that it generates the correct artifacts in the right format.
Testing the generated solution artifacts
Validate solution artifacts against the solution requirement and the business logic of the services.
5.7.1 Modeling for testing
To model for testing we use the same approach of applying transforms to the models to generate the execution artifacts, but in this case, the focus is on generating the test artifacts.
A useful approach to modeling for test is to reuse the models that describe the solution, but mark these models with testing elements. Marking the models with test elements enable us to understand the boundaries, the system under test, and the test data. The generated test artifacts may be as simple as stub objects and methods, through to test services that simulate a live system, and may be test scripts to run a test harness. Another approach is to use the model to seed the code, and then use the stubbed out code to generate test cases.
Our focus here is to illustrate the methods for modeling for test and to discuss practices for testing in an MDD project. To this end, we use our service integration example to evaluate possible ways of modeling for test.
5.7.2 Applying test patterns
Our pattern language may also contain test patterns. In our SOI example, we captured the Application pattern for the updateCustomerDetails example in the format shown in Figure 5-1.
Figure 5-1 The ESB Application pattern
Our test patterns capture the expertise needed to test the solution in the different environments. For instance, during the end-to-end testing of the
updateCustomerDetails service in the capability environment, there is a need to connect the provider facade to the required external provider. Since the external provider may be a live system that we cannot run tests against, there is a need to generate a test provider. The test provider is a simulator that provides all the public interfaces of the external provider and supports all required data and message types. ESB <<External Requester>> <<Provider Facade>> <<Internal Service>> <<Requester Facade>> <<External Provider>>
We provide an
external entities test pattern
in RSA that generates a test provider or requester based on the definitions of the external requester or provider. This test provider or requester is connected to the required facade service (as illustrated in Figure 5-2) to ensure the necessary operation calls are generated.Figure 5-2 ESB Application pattern with a testing pattern applied
Using the patterns in this example enable us to capture and apply domain knowledge based on the environments and testing practices used in the project. The application of the patterns could have occurred with the manual
augmentation of the models with test clients, test services, and stub classes ensuring that they reflect the required definitions. In either case, the generated artifacts, in the form of methods, classes, projects and so on, may be packaged separately or may be inline with the real solution artifact, depending on
complexity, and the packaging and deployment policies.
5.7.3 Modeling using the UML testing profile
The UML testing profile provides a formal extension to UML that defines tests for our system captured using UML models. The Object Modeling Group (OMG) UML Testing Profile specification describes the UML testing profile as a language for designing, visualizing, specifying, analyzing, constructing, and documenting test artifacts. It is a language you can apply to testing systems in a wide variety of application domains, whatever object or component technologies were used to build the applications. The UML testing profile can simply describe test systems, or it can be used with UML to handle system and test artifacts together.
The UML testing profile has the following characteristics:
It is based upon the UML meta-model and extends UML with test specific concepts.
It enables the specification of tests for static and dynamic aspects of UML models. ESB <<External Requester>> <<Provider Facade>> <<Internal Service>> <<Requester Facade>> <<External Provider>> <<Test Provider>>
It integrates with UML and existing testing technologies and standards (for example, JUNIT and TTCN3).
The UML testing profile is organized in four logical groups (descriptions come from the OMG UML testing profile specification) of test concepts:
Architecture defining concepts related to test structure and test configuration
Data defining concepts for test data used in test procedures
Behavior defining concepts related to the dynamic aspects of test procedures
Time defining concepts for a time quantified definition of test procedures The UML testing profile addresses black-box conformance testing and as such the system under test (SUT) is not specified as part of the test model. It is only accessible via its publicly available interfaces and operations. No information about the internal structure of the SUT is available for use, because it is a black-box. The test architecture package imports the model of the SUT in order to get the necessary access rights.
In our example, we would treat the ESB and contained elements as the SUT, and use the UML testing profile to define the test cases, test elements, test behavior, test data, verdicts, and so on, that enable the generation of our testing artifacts and the subsequent test exercise in JUNIT. The creation of a transformation to handle the profile and models that had the UML testing profile applied is not covered here. We left that as an exercise for you.
For more information about model-driven testing, see:
http://www.agedis.de/
http://www.haifa.il.ibm.com/projects/verification/mdt/tools.html
http://heim.ifi.uio.no/~janoa/wmdd2004/presentations/alan.pdf
5.8 Summary
In this chapter, we introduced key ideas behind lifecycle management in a model-driven development project. We also provided an outline of certain lifecycle activities that model-driven development can improve, such as testing and deployment.
Chapter 6, “Model-driven development in context” on page 73, considers some