Test scenario syntax

The test scenario syntax is the set of statements that you can write to load entity loaders, submit event sequences, and run tests in a single test file. In a test scenario, you can write tests to check the values and attributes of your entities, and the state of your events.

Purpose

Test scenario files are stored in the solution test client project. To test the values of your entities, entity attributes, and the state of your events, you can load entities, submit events, and then use the available constructs to run tests on the entities and events on your test server.

Syntax

The following syntax shows the constructs that you can use when you write a test scenario. 

[using definitions from "<entity loader file>" ;]

[load entities from "<entity loader file>" ;]
[load entities from:
 - "<entity loader file>" ;]

[submit events from "<event sequence file>" [, time-stamped <date & time>] ;]
[submit events from "<event sequence file>" [, time-stamped calendar duration] ;]
[submit events from :
   - "<event sequence file>" ;]

[continue processing until <date> ;]
[continue processing for <calendar duration> ;]

[check that <entity> <exists/does not exist> ;]
[check that <event aggregate> is [at least/at most/between <number> and/less than/more than/not/strictly between <number> and] <number> ;]
[check that for <entity> [identified by <entity id>] : 
   - <list of tests> ;]
[check that for <the event>/<all events> in the events emitted [by <agent>][where <test>] : <list of tests> ;]
[check that there are <number> <events> in the events emitted [by <agent>] [where <test>] ;]

[empty the events emitted ;]

The events that you want to check can be filtered by various criteria, such as events emitted by specific agents. To match multiple agents, you can add an asterisk (*) to the end of an agent string.

Table 1. Constructs for test scenarios
Construct Description Example

check that <entity> exists/does not exist ;

Detects the existence or absence of a specific entity. 

check that the customer "Betty" exists ;
check that <event aggregate> is [at least/at most/between <number> and/less than/more than/not/strictly between <number> and] <number> ;

Checks the value of a global event aggregate at the current point in a test scenario.

 
check that 'the number of purchases this month' is between 7 and 10 ;

check that for <entity> : <list of tests> ;

Verifies the expected results of a list of tests on a specified entity. This construct checks that the values of your entity correspond to the values expected in your list of tests.

 
check that for the customer "Betty" :
   - the name of this customer is "Betty"
   - the occupation of this customer is "Software Architect" 
   - the address of this customer is not null ;

check that for <entity> identified by <entity id> : <list of tests> ;

Verifies the expected results of a list of tests. This construct identifies an entity by the ID and checks the values that you expect from your list of tests.

 
 check that for the customer identified by customerName :
   - the name of this customer is "Betty"
   - the occupation of this customer is "Software Architect"
   - the address of this customer is not null ;

check that for <the event> in the events emitted [by <agent>][where <test>] : <list of tests> ;

Checks the attributes of an event in a specified subset of the events that are emitted, since the start of the test

 
check that for the status change in the events emitted
    by "CustomerLoyaltyAgent" :
    - the customer id of the customer of this status change is "Fred"

check that for <all events> in the events emitted [by <agent>][where <test>] : <list of tests> ;

 Checks the attributes of all members of a specified subset of the events that are emitted, since the start of the test. 
check that for all fraud alerts in the events emmitted :
   - the importance of each fraud alert is HIGH ;

check that there are <number> <events> in the events emitted [by <agent>] [where <test>] ;

Checks the number of events emitted either by a specific agent, by an event, or by both.

 
check that there are 5 fraud alerts in the events emitted by 
check that the number of fraud alerts emitted ;

continue processing until <date> ;

Simulates the passing of time from the date of the last event in an event sequence to the date and time that you define in the continue processing until <date> construct.

 
continue processing until 13/10/2016 11:10:00 PM ;

continue processing for <calendar duration> ;

 Simulates the passing of time from the date of the last event in an event sequence for time specified by the <calendar duration> construct. 
continue processing for 30 minutes ;

empty the events emitted ;

Disregards the events that are previously emitted in the test scenario. The events that are emitted by the solution before this statement are ignored in subsequent "check" statements. 

 
empty the events emitted ;

load entities from "<entity loader file>" ;

Loads entities from a single entity loader file.

 
load entities from "customer" ;

load entities from: - "<entity loader file>" ;

Loads entities from a list of entity loader files.

 
load entities from: 
   - "customers"
   - "accounts" ;

submit events from "<event sequence file>" [, time-stamped <date & time>] [, time-stamped <calendar duration>];

Submits events from a single event sequence file.

If the event sequence that you submit uses the time-stamped by the test scenario construct, you must specify an absolute timestamp on the first submitted event. All subsequent events can use calendar duration timestamp that is relative to the event that precedes it.

 
submit events from “daily purchases” , time-stamped 1/1/2016 9:00:00 AM ;
submit events from “daily purchases” , time-stamped 1 day later ;

submit events from: - "<event sequence file>" ;

Submits events from a list of event sequence files. 

submit events from: 
   - "purchases"
   - "returns" ;

using definitions from: -"<common definitions file>" ;

Specifies the common definitions file or files from which an entity loader, event sequence, or common definitions file uses the definitions. When you use this construct, it must be used in the header of the file and precede all of the other constructs.

 
using definitions from: 
   - "customer_ids"
   - "items" ;

Example

The following test scenario uses common definitions, an entity loader, and four event sequences. In the first test, you check that the alert in the alerts event sequence is low. Then, you clear the events before running various checks on a customer named Fred. The test moves forward in time to 11/06/2015 by using the continue processing until construct.

using definitions from "customer definitions" ;

submit events from "alerts" time-stamped 23/3/2016 11:00:00 AM ;  
check that for the alert in the events emitted : 
  - the level of this alert is low ; 

submit events from "alerts" , time-stamped 2 hours later ; 
check that for the alert in the events emitted :
  - the level of this alert is medium ; 

empty the events emitted ;

load entities from "customers" ;
submit events from "none to bronze" ;

check that for the customer identified by 'Fred' : 
   - the age of this customer is between 18 and 65
   - the address of this customer is not null
   - the phone number of this customer is not null ;
check that for the customer 'Fred' :
    - the status of this customer is BRONZE ;

submit events from "bronze to silver" ;

check that for the status change in the events emitted
    by "CustomerLoyaltyAgent" :
    - the customer id of the customer of this status change is "Fred"
    - the new status of this status change is SILVER ;
check that for the customer 'Fred' :
    - the status of this customer is SILVER ;

submit events from "silver to gold" ;

check that for the customer 'Fred' :
    - the status of this customer is GOLD ;

continue processing until 11/6/2015 ;

check that for the customer 'Fred' :
    - the status of this customer is SILVER ;