Connecting Your Tests to an Implementation

Spec Explorer supports two topologies for connecting generated test cases to the implementation of your System Under Test (SUT). They can be either connected directly or through a test adapter.

Connecting them directly means to declare the actual methods and events of your implementation as actions in a Cord configuration (either one by one or using the “action all” option to extract them for the SUT). Consequently, the generated test code will call directly into your SUT and expect the events it raises. This option can only be applied to managed code implementations that expose an API rich enough to allow testability.

Direct Connection

A test adapter is a (fairly thin) software layer that sits between your test cases and your SUT. When you create a test adapter, you declare the adapter methods and events as actions in a Cord configuration instead referring directly to the SUT. As a result, the generated test code will call methods (and expect events) in the adapter. The adapter has the task of turning these calls into SUT calls, usually performing some translation or marshaling. This architecture must be used when the implementation is not managed, when the communication is remote, when there is a test infrastructure in the middle (for example, to control the SUT’s UI), to raise the level of abstraction of modeling and testing, etc. Adapters are a way to get around testing environments that otherwise would be hard to tackle by managed test code derived solely from modeling. Thus they greatly extend the power of Spec Explorer.

Connection through a Test Adapter

It is possible in both approaches that the modeler and the adapter or SUT implementer collaborate by agreeing on the action interface as a contract and then proceed in parallel: the modeler ultimately being a consumer of the agreed interface and the implementer being the provider of the functionality behind the interface. Only at generated test case run time must the adapter or SUT interface be ready for execution. The modeler would declare the actions in Cord as abstract and use rules in the model program and Cord scenarios to model expected system behavior.