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:
1 2 3 4 5 6 7 8 9 10 | 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 | 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | 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:
1 2 3 4 5 | 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:
1 2 3 4 5 6 7 8 9 10 | 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 |