Page Comparison

...

Definition

DEFINITION
The

DoWithInterpreter

WorkflowInterpreter 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. When a sequence of action is executed, Image Modified confirms that each action has successfully been performed.

Image Removed

Image Added As for all other interpreters, the first row of the

DoWithInterpreter

WorkflowInterpreter specifies the name of the interpreter and the name of the sequence of actions to be tested. What makes the DoWithInterpreter particular is that it only has to be defined once for all the sequences of actions expressed in a page. Obviously, the DoWithInterpreter must be define before any sequence of actions. The following rows are used to express specific actions. The form of each row of a

DoWithInterpreter

WorkflowInterpreter shall respect the following rules: a row shall begin with a part of the action description, each parameter shall be isolated in a cell, each parameter shall be separated by parts of the action description. An action description can be left blank in order to separate two parameters. The

DoWithInterpreter

WorkflowInterpreter provides a minimum of keywords used to define a specific action. The

DoWithInterpreter

WorkflowInterpreter may also be expressed in Bullet List form or Number List form.

...

Specific Keywords

 offers a list of useful keywords to support the Business Expert. Those keywords are placed at the beginning of an action row.

...

Coloring

Image Modified will visually show the test result by coloring each testing cell:

Standard form (without keyword)	Only the Action description will be colored.
Accept	Only the cell containing the keyword Accept will be colored.
Check	The cell containing the expected value will be colored. In case of a failure, Image Modified will show the expected and the returned values.
Reject	Only the cell containing the keyword Reject will be colored.
Display	A new cell at the end of the row will be colored containing the returned value.

...

Writing fixtures for

...

Workflow tables

As we've seen in the Do With Workflow 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 Do With Workflow specification.

...

 Fixture for Bank

Consider the first example of business flow described in Writing a Do With Workflow specification, shown again below.

The first table indicates to use a DoWithInterpreter WorkflowInterpreter , which handles a business flow expressed as a sequence of tables. The fixture Bank will do the mediation with the application under development.

...

The fixture code to support this example in Java is the class BankFixture shown below.

...

Show me the code

public class BankFixture 
{
    private Bank bank;

    public BankFixture()
    {
        bank = new Bank();
    }

    public boolean openCheckingAccountUnderTheNameOf(String number, String firstName, String lastName)
    {
        return bank.openCheckingAccount(number, new Owner(firstName, lastName)) != null;
    }

    public Money thatBalanceOfAccountIs(String accountNumber) throws Exception
    {
        BankAccount account = bank.getAccount(accountNumber);
        return account.getBalance();
    }
}

That class follows the general rules of fixtures described in Workflow Validation (Do With) Fixture Conventions. It provides public instance methods openCheckingAccount and thatBalanceOfAccount to map respectively to the actions open checking account and that balance of account.

...

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,  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.

...

1. It calls the method thatBalanceOfAccountIs() with the parameter 12345-67890 to get the value calculated by the system under test
2. This is a check action, so it reads the value $0.00 from the last cell of the row and compares it to the value returned by the fixture. Since the values are equal, it annotates the last cell as right, which results in the cell being colored green.

...

What happens for other return types?

...

Default Rows

Depending on the value returned by the system under test, default actions will annotate keyword cells following these rules:

• If the value is true, it annotates keyword cells right, making them appear green.
• If the value is false - indicating a failure - it annotates keyword cells wrong, making them appear red.
• If the action throws an exception, it annotates the first keyword as an exception, making it appear yellow and display a stack trace of the error.
• If the action returns another value or nothing, it ignores the result.

...

• .Check Rows

Depending on the value returned by the system under test, check actions will annotate the row following these rules:

• If the returned value matches the expected value, it annotates the last cell right, making it appear green.
• If the action returns nothing or a value that does not match the expected value - indicating a failure - it annotates the last cell wrong, making it appear red.
• If the action throws an exception, it annotates the first keyword as an exception, making it appear yellow and display a stack trace of the error.

...

Building on the Bank example

The second example in Writing a Do With Worflow Specification, shown again below, presents a more complete business flow using the bank fixture.

The fourth and last example table also contains 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.

...

In the last row of the last table, the accept special keyword is used to indicate that we expect the last call to succeed. Accept is the opposite of reject. That is, the last withdraw should not return false nor throw an exception.

...

Reject Rows

Depending on the value returned by the system under test, reject actions will annotate the row following these rules:

• If the action returns false or throws an exception - indicating a success - it annotates the reject keyword right, making it appear green.
• If the returned value is anything else or nothing - indicating a failure - , it annotates the reject keyword wrong, making it appear red.

...

Accept Rows

Depending on the value returned by the system under test, accept actions will annotate the row following these rules:

• If the returned value is anything except false or an exception - indicating a success -, it annotates the accept keyword right, making it appear green.
• If the action returns false or throws an exception - indicating a failure - it annotates the accept keyword wrong, making it appear red.

...

Show me the code

The supporting code is here:

public class BankFixture 
{
    private Bank bank;

    public BankFixture()
    {
        bank = new Bank();
    }

    public boolean openCheckingAccountUnderTheNameOf(String number, String firstName, String lastName)
    {
        return bank.openCheckingAccount(number, new Owner(firstName, lastName)) != null;
    }

    public Money thatBalanceOfAccountIs(String accountNumber) throws Exception
    {
        BankAccount account = bank.getAccount(accountNumber);
        return account.getBalance();
    }

    public void depositInAccount(Money amount, String accountNumber) throws Exception
    {
        bank.deposit(amount, accountNumber);
    }
    
    public boolean withdrawFromAccount(Money amount, String accountNumber) throws Exception
    {
        return withdrawFromAccountUsing( amount, accountNumber, WithdrawType.ATM );
    }

    public boolean withdrawFromAccountUsing(Money amount, String accountNumber, WithdrawType withdrawType) throws Exception
    {
        try
        {
            bank.withdraw(amount, accountNumber, withdrawType);
        }
        catch (Exception e)
        {
            return false;
        }
        return true;
    }

    public Collection getOpenedAccounts()
    {
        return bank.getAccounts();
    }
}

...

Combining with other types of rules

An interesting characteristic of the DoWithInterpreter WorkflowInterpreter is the ability to delegate processing of part of the table to another interpreter.

...

In the example show below, the first row of the second table indicates to process the rest of the table using a SetOfInterpreter on the value returned by the action opened accounts.

...

Interpret Rows

Depending on the value returned by the system under test, interpret actions will annotate the row following these rules:

• If the returned value is an object, it uses the interpreter specified in the first cell on that object to interpret the remainder of the table. The row is not annotated.
• If the action returns nothing, it uses the interpreter without any fixture to interpret the remainder of the table. The row is not annotated.
• If the action throws an exception - indicating a failure - it annotates the first action keyword as exception, making appear yellow and display a stack trace of the error. The remainder of the table is not interpreted.

...