From OpenTTCN DocZone

OpenTTCN DocZone   Home | Developer's corner | Knowledge base | Working documents | Documentation | Tutorials | Training | How do I | Frequently asked questions | Technical support

How do I simulate SUT if there is no SUT or codec available?^*

---

Preface

It is sometimes necessary to simulate SUT in the early stages of your test suite development project. In these early stages you may find out that part of your team responsible for codec development does not yet have a working prototype to deliver, or that there is no hardware or SUT available for testing.

In this case you may need to write some kind of simple SUT simulator to validate the early concepts you are developing in your test cases. Here we present a simple approach how you can implement a simple SUT as a TTCN-3 parallel test component written in TTCN-3 core language and provide it as a substitute for real SUT and TRI/TCI adapter transparently to the test suite so that the main body of the test suite will not even notice the difference, as it will still think that it is communicating with the real SUT.

The elegance of the presented approach is that you will not have to change a single line of code in the original test suite to make this substitution. This is possible with OpenTTCN.

We will not have to program any adapters in this example. All that we need is a useful utility called robo that comes with every standard package of OpenTTCN.

Test suite

Consider we have the following original test suite that we need to validate against our SUT simulator (file Main.ttcn):

module MyTestSuite
{

type port PortType mixed
{
    inout all;
}

type component ComponentType
{
    port PortType p;
}

type component TestSystemInterface
{
    port PortType tsiPort1, tsiPort2;
}

testcase TC_test()
    runs on ComponentType
    system TestSystemInterface
{
    map(self:p, system:tsiPort1);

    timer T := 2.0;

    p.send("REQ");
    T.start;

    alt
    {
        [] p.receive("RSP") { setverdict(pass); }
        [] p.receive { setverdict(fail); }
        [] T.timeout { setverdict(inconc); }
    }
}

}

We compile the test suite to session sim using the following command:

importer3 load sim Main.ttcn

Simulator

We will now implement a TTCN-3 module containing simulator code. The simulator algorithm is quite simple: for every "REQ" string it receives, it sends "RSP" back in response. We also add a hook function that will be called implicitly in the beginning of every test case that transparently connects our simulator to the test suite being validated.

Simulator source code (file Sim.ttcn):

module MySim
{

import from MyTestSuite all;

type component SimPTC_ComponentType
{
    port PortType sim_p;
}

// This is where we put code of our simulated SUT. This is where all its intelligence is concentrated.
function Sim_Behaviour_As_PTC()
    runs on SimPTC_ComponentType
{
    alt
    {
        [] sim_p.receive("REQ")
        {
            sim_p.send("RSP");
            repeat;
        }
    }
}

// Called implicitly from the MTC before the first statement of a test case is executed.
function Sim_Start_Hook() runs on ComponentType
{
    var SimPTC_ComponentType simPtcRef := SimPTC_ComponentType.create;
    map(simPtcRef:sim_p, system:tsiPort2);
    simPtcRef.start(Sim_Behaviour_As_PTC());
}

}

We compile the module containing simulator code to the same session sim using the following command:

importer3 load sim Sim.ttcn

Test setup

We now need to start our robo adapter in a special configuration using the following command:

robo -s 127.0.0.1:5500:sim TRI:tsiPort1 TRI:tsiPort2 TRI:tsiPort2 TRI:tsiPort1

It registers the robo adapter to the sim session. The openttcnd server is located on the local host (127.0.0.1), port 5500. "TRI:tsiPort1 TRI:tsiPort2" pair of parameters establishes a unidirectional connection from TSI port tsiPort1 to TSI port tsiPort2, instructing robo adapter to forward every request it receives on TSI port tsiPort1 to TSI port tsiPort2, but not vice vesa. The second pair of parameters, "TRI:tsiPort2 TRI:tsiPort1", instructs robo to establish the connection between tsiPort1 and tsiPort2 in the opposite direction, thus making communication between TSI ports tsiPort1 and tsiPort2 bidirectional.

We also need to register our startup hook Sim_Start_Hook() as follows:

session set property sim PRETEST_FUNCTION=Sim_Start_Hook

You could also use a fully-qualified name for the hook function in the command above if the symbol were ambiguous in the test suite.

Hook function registration is persistent and it survives starting and stopping openttcnd. It disappears if you delete a session or unregister the relevant property.

The robo adapter self-registration to sim is non-persistent and you will need to perform it once again if you restart openttcnd.

Running test case

Now everything is ready to run our test case with simulated SUT. This can be done using the following command:

tester run sim TC_test

Here is an example of the test run output:

*****************************************************************************
*** RUNNING TEST CASE TC_test

Tester : {14:14:50.375} : // Time: 14:14:50.375. Date: 14/Mar/2008. MOT version: TC: 2.57.0.RC4.0.
mtc : {14:14:50.685} : map(simPtcRef:sim_p, system:tsiPort2);
mtc : {14:14:50.690} : simPtcRef.start(Sim_Behaviour_As_PTC()); // Component is started.
mtc : {14:14:50.690} : // CASE TC_test STARTED
ptc1 : {14:14:50.689} : // PTC RUNNING ON Sim_Behaviour_As_PTC STARTED
mtc : {14:14:50.707} : map(self:p, system:tsiPort1);
ptc1 : {14:14:50.725} : sim_p.receive(charstring : "REQ");
mtc : {14:14:50.739} : p.send(charstring : "REQ");
mtc : {14:14:50.739} : T.start(2.0); // Timer is started: duration 2 s.
mtc : {14:14:50.754} : p.receive(charstring : "RSP");
mtc : {14:14:50.754} : setverdict(pass);
mtc : {14:14:50.759} : // CASE TC_test FINISHED
mtc : {14:14:50.759} : // VERDICT TC_test PASS
ptc1 : {14:14:50.769} : sim_p.send(charstring : "RSP");

*****************************************************************************
*** TEST EXECUTION SUMMARY

Pass    Fail    Inconc    None    Error    Total    Duration
1       0       0         0       0        1        00:00:01

^*The feature presented in this article is available starting with OpenTTCN 2.57.0.RC5.