Implement the Mock Call Step

We will finish our test case by initiating the mock call with our virtual phones.

1. Implementing the Mock Call Step

Revert the Feature File back to the following:

Feature: phoneConnection

  Scenario: Phone connection
    Given phones as A and B:
      * of type Android
    And A starts a call to B as A2B:
      * call duration is 1 seconds

    Then within 30 seconds, expect the call A2B to connect
    Then within 10 seconds, expect the call A2B to disconnect

2. Create the Second Stepdef

Copy and paste the following Stepdef under the first Stepdef in the CustomTelephonyStepdefs.steps file:

stepdef "{} starts a call to {} as {ident}" / firstPhone, secondPhone, callName, details /
    println(firstPhone)
    phoneCallMap := Telephony.parseCallDetails(firstPhone.id, secondPhone.id, details)

    println("CallDetails:")
    for k,v in phoneCallMap
        println(k + " : " + v)
    end

    firstPhone.props["customProperty"] := "hello"

    setContextObject(callName, phoneCallMap)
end

Note
Here both {} and {ident} are both used as parameter placeholders. The difference is important, and relates to how the variables are taken from the Feature File:
* In the first case, {}, the Feature File passes the value of the expression that is defined. For example, if A is passed from the Feature File, the variable A is passed. This is a VirtualPhone, which has an id, and a map of properties.
* With {ident}, whatever is written in the Feature File is passed without evaluation. In this case, if A is passed, the string ”A” will be passed through to the Stepdef.

This means that for the {} starts call to {}... Stepdef, both features of placeholder are used. It is possible to use A and B with {}, as prior to this step, both A and B have been set up in the environment. However, there is no variable called A2B, therefore this must be passed as a string.

3. Execute the Test And Review the Results

Return to phoneConnection.feature and execute it by right-clicking and selecting Run phoneConnection.feature.... The call details passed to the step are parsed, which results in a map.

Click on the step And A starts a call to B as A2B: to see the maps' contents. It will look something like this:

13:17:49.401 [DEBUG]: Observing step 0.0: A starts a call to B as A2B:
13:17:49.404 [INFO]: Step started: A starts a call to B as A2B:
            * call duration is 1 seconds
13:17:49.405 [INFO]: com.tryge.autotest.server.utils.VirtualPhoneImpl@dbae786
13:17:49.422 [INFO]: CallDetails:
13:17:49.425 [INFO]: detectCallWithinSeconds : 30
13:17:49.426 [INFO]: callDuration : 1
13:17:49.429 [INFO]: callDurationUnit : seconds
13:17:49.434 [INFO]: hangupBy : CALLER
13:17:49.435 [INFO]: callerConnectsWithinSeconds : -1
13:17:49.437 [INFO]: calleeConnectsWithinSeconds : -1
13:17:49.438 [INFO]: callerId : A
13:17:49.438 [INFO]: callerDestination : CallDestination:Phone:A
13:17:49.44 [INFO]: calleeId : B
13:17:49.441 [INFO]: calleeDestination : CallDestination:Phone:B
13:17:49.442 [INFO]: dialFormat : int
13:17:49.443 [INFO]: detectFormat : any
13:17:49.443 [INFO]: ringDuration : 3
13:17:49.444 [INFO]: callForward : {}
13:17:49.444 [INFO]: speechChannelMonitor : null
13:17:49.445 [INFO]: notDetectCallWithinSeconds : -1
13:17:49.446 [INFO]: callRelayTo :
13:17:49.446 [INFO]: signaledNumber : null
13:17:49.449 [INFO]: callerAbandonsTheCall : false
13:17:49.45 [INFO]: calleeRejectsTheCall : false
13:17:49.451 [INFO]: calleeDoesNotAnswer : false
13:17:49.451 [INFO]: networkRejectsTheCallWithinSeconds : -1
13:17:49.452 [INFO]: Step ended with status: passed
13:17:49.452 [DEBUG]: Finished observing step.

A property is set here in the VirtualPhone. The props map acts as a data container that may be used to pass data around between steps.

4. Add Assertion Steps

Copy and paste the following Stepdef into your CustomTelephonyStepdefs.steps file, resulting in three distinct Stepdefs:

stepdef "within {} seconds, expect the call {ident} to {ident}" / seconds, callId, actionType /
    simulatedActionSeconds := 3
    delay(simulatedActionSeconds) // simulate waiting for the phones to connect
    assert seconds > simulatedActionSeconds // will fail if we waited too long
end

We simulate a call action happening after 4 seconds, after which we check that we did not have to wait too long (in this case the test will be failed due to the assertion).

With this timeout setting, the test passes. If we change the Feature File to have a shorter timeout, for example using Then within 2 seconds, expect the call A2B to connect, then the test will fail. For example:

13:37:32.94 [DEBUG]: Observing step 0.1: within 2 seconds, expect the call A2B to connect
13:37:32.94 [INFO]: Step started: within 2 seconds, expect the call A2B to connect
13:37:32.941 [INFO]: DELAY REQUEST: 3 seconds
13:37:35.945 [INFO]: Step ended with status: failed
13:37:35.945 [INFO]: java.lang.RuntimeException:
    At qitasc/projects/demo/libs/tutorial/customPhoneSteps.steps:23,11 Expression 'seconds>simulatedActionSeconds' evaluates to false.
    At qitasc/projects/demo/libs/tutorial/customPhoneSteps.steps
    at at.inaut.lang.common.CompiledModuleImpl.invoke(CompiledModuleImpl.java:131)
    at at.inaut.lang.common.CommonStepDefinition.invoke(CommonStepDefinition.java:31)
    at ✽.Then within 2 seconds, expect the call A2B to connect