Definition
The ScenarioInterpreter is used to express interactions with the system under development that must be performed in a particular order. This form of specification provides information about the business flow.
...
As for all other interpreters, the first row of the ScenarioInterpreter specifies the name of the interpreter and the name of the sequence of actions to be tested. What makes the ScenarioInterpreter particular is that it only have to be defined once for all the sequences of actions expressed in a page. Obviously, the ScenarioInterpreter must be define before any sequence of actions.
The ScenarioInterpreter may also be expressed in Bullet List form or Number List form.
Coloring
GreenPepper will visually show the test result by coloring a complete row or words inside the row:
...
When the action has been executed successfully, GreenPepper will display the returned value in gray.
Writing fixtures for Scenario tables
As we've seen in the Scenario definition, a sequence of tables is used to express a business flow in the application under development.
...
This page shows the fixture code that supports the examples introduced in the Writing a Scenario specification.
Fixture for Bank
Consider the first example of business flow described in Writing a Scenario specification, shown again below.
...
The second table indicates to perform the action of opening a checking account 12345-67890 under the name of Spongebob Squarepants on the system under development. That action will result in a call to a method from the Bank fixture. The method will be found using Regular Expression assigned to an annotation.
...
Annotation & Regular Expression
To resolve the method to call, the ScenarioInterpreter will look at all fixture methods annotated with the following annotations and will try to match the action content to the regular expression on it. Parameters will be captured by the regular expression itself (using capture group).
| Info | ||
|---|---|---|
| ||
.Net annotation are in fact Attribute and are declared like [Given]. |
@Given
@Given("[regular expression]")
...
A Given annotation will be use when you need to put the system in a know state before a user interact with it. A good example will be to prepare the data in the system to be available for the next action calls. In our Bank example, this will represent the opening of the checking account action.
@When
@When("[regular expression]")
...
A When annotation will be use for transiting the system to another state. A good example will be to interact with the system. In our Bank example this will represent deposit or withdraw actions.
@Then
@Then("[regular expression]")
...
A Then annotation will be use to verify the result of interactions on the system. A good example will be to check if an event has been raised. In our Bank example, this will represent the verification of the balance account.
@Check
@Check("[regular expression]")
...
A Check annotation will be use to verify the result of the action (boolean result equality). A good example will be to check if we can proceed with an action. In our Bank example, this will represent the verification whenever we can withdraw a certain amount.
@Display
@Display("[regular expression]")
...
The fixture code to support this example in Java is the class BankFixture shown below.
Show me the code
| Code Block | ||||
|---|---|---|---|---|
| ||||
public class BankFixture
{
private Bank bank;
public BankFixture()
{
bank = new Bank();
}
@Given("open (\\w+) account (\\d{5}\\-\\d{5}) under the name of ([\\w|\\s]*)")
public void openAccount(String type, String number, Owner owner)
{
if ("checking".equals( type ))
{
bank.openCheckingAccount( number, owner );
}
else if ("savings".equals( type ))
{
bank.openSavingsAccount( number, owner );
}
}
@Then("verify that balance of account (\\d{5}\\-\\d{5}) is (\\$\\d+\\.\\d\\d)")
public void theBalanceOfAccount(String number, Expectation expectedBalance) throws NoSuchAccountException
{
Money actualBalance = bank.getAccount( number ).getBalance();
expectedBalance.setActual( actualBalance );
}
} |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
public class Bank {
private final HashMap<String, BankAccount> accounts;
public Bank()
{
accounts = new HashMap<String, BankAccount>();
}
public boolean hasAccount(String accountNumber)
{
return accounts.containsKey(accountNumber);
}
public BankAccount getAccount(String accountNumber) throws NoSuchAccountException
{
if (!hasAccount(accountNumber)
throw new NoSuchAccountException(accountNumber);
return accounts.get(accountNumber);
}
public CheckingAccount openCheckingAccount(String number, Owner owner)
{
if (hasAccount(number)) return null;
CheckingAccount account = new CheckingAccount(number, owner);
accounts.put(number, account);
return account;
}
} |
How is the example interpreted?
When it runs this example, GreenPepper reads the first table to decide on the interpreter and fixture to use and start testing from the second table, which is the first test table.
...
Find a method that match the action content using regular expression defined on annotated method
It calls the method theBalanceOfAccount() with the parameter 12345-67890 to get the value calculated by the system under test and the Expectation object instance
This is a Then annotation. The method will set the actual value on the Expectation object instance. GreenPepper will then verify the Expectation object to see if it match the value $0.00. If the values are equal, it annotates the value $0.00 as right (green) or wrong (red) if not
Building on the Bank example
The second example in Writing a Scenario specification, shown again below, presents a more complete business flow using the bank fixture.
...
The fourth and last example tables contain more several rows. In a sequence of actions, all of the rows in a table are executed, so several actions can be grouped in a table if that helps improve clarity.
Show me the code
The supporting code is here:
| Code Block | ||||
|---|---|---|---|---|
| ||||
public class BankFixture
{
private Bank bank;
public BankFixture()
{
bank = new Bank();
}
public BankFixture()
{
this.bank = new Bank();
}
@Given("open (\\w+) account (\\d{5}\\-\\d{5}) under the name of ([\\w|\\s]*)")
public void openAccount(String type, String number, Owner owner)
{
if ("checking".equals( type ))
{
bank.openCheckingAccount( number, owner );
}
else if ("savings".equals( type ))
{
bank.openSavingsAccount( number, owner );
}
}
@Then("verify that balance of account (\\d{5}\\-\\d{5}) is (\\$\\d+\\.\\d\\d)")
public void theBalanceOfAccount(String number, Expectation expectedBalance)
throws NoSuchAccountException
{
Money actualBalance = bank.getAccount( number ).getBalance();
expectedBalance.setActual( actualBalance );
}
@When("deposit (\\$\\d+\\.\\d\\d) in account (\\d{5}\\-\\d{5})")
public void deposit(Money amount, String number)
throws Exception
{
bank.deposit( amount, number );
}
@When("withdraw (\\$\\d+\\.\\d\\d) from account (\\d{5}\\-\\d{5})")
public void withdraw(Money amount, String number)
throws Exception
{
bank.withdraw( amount, number, WithdrawType.ATM );
}
@Check("can't withdraw (\\$\\d+\\.\\d\\d) from account (\\d{5}\\-\\d{5})")
public boolean cannotWithdraw(Money amount, String number)
{
try
{
bank.withdraw( amount, number, WithdrawType.ATM );
return false;
}
catch (Exception e)
{
return true;
}
}
@Check("can withdraw (\\$\\d+\\.\\d\\d) from account (\\d{5}\\-\\d{5})")
public boolean canWithdraw(Money amount, String number)
{
try
{
bank.withdraw( amount, number, WithdrawType.ATM );
return true;
}
catch (Exception e)
{
return false;
}
}
public Collection<BankAccount> getOpenedAccounts()
{
return bank.getAccounts();
}
} |
Combining with other types of rules
An interesting characteristic of the ScenarioInterpreter is the ability to delegate processing of part of the table to another interpreter.
...