Organizing models by how you test workflows

Testing workflows can dictate model organization. Although testing teams require read‑only access to the model elements, they need to manage test plans, procedures, results, scripts, and fixtures (often at multiple levels of abstraction). Testing typically occurs on primary levels: unit testing, integration, and validation.

Because unit‑level testing consists mainly of white box, design, or code‑level tests and often uses additional model elements constructed as test fixtures, it is advisable to locate these elements together with the corresponding parts of the model. So, if a class myClass has testing support classes, such as myClass_tester and myClass_stub, you might want to keep them together, either within the same package or in another if a peer will do the testing (as long as it is a different CI from that of the model elements under test).

Integration and validation tests are not as tightly coupled as unit‑level tests, but the testing team might construct model elements and other artifacts to assist them. Because the creators of the model elements do not typically do these tests, independent access is required, so the model elements should be in different CIs.

Efficiently constructing and testing prototypes is a crucial part of the development life cycle. Testing involves both tests against the architecture (integration) and against the requirements (validation) for the entire prototype. There can be any number of model elements constructed for a particular prototype that need not be used anywhere else. It makes sense to keep these elements near that build or prototype. Store test fixtures, to be applied to many or all prototypes, in a location where independent access from any given prototype is possible.