Static vs. Instance-Based Models

Many Spec Explorer users have asked the question of how and when to choose between static or instance-based at the time of creating a model.

The Base Solution Wizard (Visual Studio File menu -> New -> Project… -> Visual C# -> Spec Explorer Base Solution) shortly explains in its second step the difference between these two kinds of models, while leaving the choice to the user:

Spec Explorer Base Solution Wizard

So I figured it would be worth explaining the reasons to pick one or the other in this blog post. I’ve explained in a previous one two different ways to connect your test cases: directly or through a test adapter.

If you decide to go with the latter, the design of the test adapter itself is one place where the static-vs.-instance-based decision can be made. A static adapter can be used to control an instance-based SUT and vice-versa. The test adapter is just another component in your (testing) system. The rationale and constraints involved in this decision are the same one would take into consideration for designing any component in an object-oriented design. Moreover, this is not an all-or-nothing choice. Static and instance-based members can be combined in the same adapter as needed.

Action declarations in Cord configurations are used to connect the test cases to an external entity (either the SUT or an adapter). Generally, if your test cases will call static methods in the adapter or SUT, your actions will be static, whereas you will have instance-based actions if the methods to be called are instance-based. So the actual choice between static vs. instance-based actions is not really made by the modeler, but rather by whoever designs that external entity. Of course, they could be the same person, but would mean wearing two hats anyway.

The implication of having instance-based actions is that model steps will need to invoke the actions on objects that are not only known at model-exploration time, but also at test execution time. This means that the receiver of an instance-based action (“this” in C#) must have been the output of an action in a previous step. If a rule creates an object but doesn’t return it in its associated action, future steps will not be able to use it as a receiver.

Now a second choice point is reached when creating a model program. Spec Explorer allows mapping instance-based actions to static rule methods (and in some cases, the other way round). The usual recommendation is not to make this switch, as modeling static actions with static rules (and instance-based actions with instance-based rules) is usually more natural. But we’ve seen cases where a modeler doesn’t agree with the design choice made at SUT or adapter design time and believes better model clarity can be achieved by using a different approach for the rules.

The goal, as with any design, is to keep your model simple to understand and to maintain, while achieving the desired behavior.