1. Writing my first executable specification

Writing an executable specification for a Calculator program

Consider your customer wants to create a calculator.

The business expert on Calculators explains to the developer the rules for calculation. The first specification is: The calculator should be able to add two numbers. To support the specification, the business expert also provide an example: 6 + 3 = 9.

In order to be executable in , the specification must be expressed in a specific form :

The first line of the specification explains that we have particular RULES FOR our Calculator. The calculator receives two numbers and it gives you back the sum of those two numbers. Once the calculator will be developed, we will be able to execute the specification to test the functionality.

Execute the specification

If you hit the Execute button on the top of the page, you will get the result of your test.

How it works?

Once you click on the Execution button,  calls the actual software containing the code for the Calculator. It sends the parameters x (equal to 6) and y (equal to 3) to the Calculator to obtain the resulting sum of those two numbers. The "?" symbol next to the word "sum" is a key-sign that indicates to  that a test must be performed.

In that particular example,  will query the calculator application and compare the value returned by the system with the value specified by the business expert (in the "sum?" column). Since the result returned by the system is the same as the expected result, the cell is colored in green by . The business expert is now confident that the Calculator is able to add two numbers.

Adding another example

Once the Calculator is developed, the business expert may think about new examples that he would like to test. The business expert add new row in the Rule For table and execute the test (no coding is needed here).

When there is an error,  colors the cell in red.
In the new example, it is clear that the expected value provided by the business expert is not correct. But the error could have been in the system.

Adding new specifications to our Calculator

The business expert wants to improve the Calculator: The Calculator should be able to perform product and quotient of two numbers.
The new rules can be written in a way similar to the "sum" specification. In case of an expected errors, the keyword error may be used in order to test those special cases.

2. Rule Validation (Rule For)

Definition

Specific Keywords for expected values

 offers a list of useful keywords to support the Business Expert.

Empty cells	When a test cell is left blank,  only shows the returned value
error	When you expect an error, specify it in the cell to test that particular behavior

Coloring

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

Here is an example of cell coloring:

Writing a Rule For Specification

When do we use the RuleForInterpreter?

The RuleForInterpreter is used to express concrete and measurable business rules. The business rules are often related to all kind of calculations.

When a table of rule is executed,  compares the values returned by the system under development against the expected values defined by the Business Expert.

First row: Identification of the Rule For

In a Rule For table, the first row specifies the name of the interpreter and the name of the rules to be tested.
The business expert should be clear in the identification of the set of rules.

• Example Division : A simple system performing divisions. In that particular case, we could define the set of rules as Division which leads to:

  rule for

  Division

• Example Mortgage : A Mortgage management system with the following specifications:
  "Whenever the down payment on the property is less than 25% of the sale price, the buyer has to pay a premium for insuring the mortgage. The premium fee amount is 2.5% of the financed amount (which is sale price - down payment)."
  For that particular calculation we could identify the set of rules as:

  rule for

  insurance premium fee calculation

Second row: the Header

The second row is called the header row and serves to distinguish between the given values and the expected values. Given values serve as inputs to the system, whereas expected values serve as comparison values against values that are actually returned by the system. When a column header ends with special characters ? or (), it denotes an expected value.

• Example Division : The given values for that example are the dividend and the divisor. The expected value is the quotient.

  rule for	Division
  dividend	divisor	quotient?

• Example Mortgage : The given values for that example are the sale price and the down payment. The expected value is the premium fee.

  rule for	insurance premium fee calculation
  sale price	down payment	premium fee?

Third and following rows: Examples

The remaining rows capture the examples. They are the executable test rows.

Final expression of the Division example

Final expression of the Mortgage example

Specification: "Whenever the down payment on the property is less than 25% of the sale price, the buyer has to pay a premium for insuring the mortgage. The premium fee amounts is 2.5% of the financed amount (which is sale price - down payment)."

When there is no expected value specified in a cell,  provides the value calculated by the system under development. The business expert could use that functionality to facilitate the comprehension of a rule. In this example, the financed amount of mortgage can be evaluated as an intermediate result.

Execution of specifications

Based on those executable specifications, the developers are now ready to code the functionality and the fixture (the fixture is the link between the system under development and the executable specification). Once this is done, the specification can be executed by clicking on the Execute button on the top of the page.

During execution,  colors only the cells of the column "expected values".  will color the cell green if the returned value equals the expected value. If the returned value is not the same,  will color the cell red and will show the expected and the returned values. Finally, if an expected value is left blank by the business expert,  colors the cell in gray to signify that no test was performed and shows the returned value.

3. List Validation (List of, Set of, Superset of, Subset of)

Definition

Specific keywords

None

Colouring

 will visually indicate the test result by colouring the rows:

Particular behaviour for the list of interpreters:
Since the ListOfInterpreter expects to match exactly the expected list and the list returned by the SUD,  compares each cell of the table separately. If the expected value is different from the returned value,  colours the cell in red and provide the two values.

Particular behaviour for the superset of interpreters:
Since the SupersetOfInterpreter accepts that the specification may contain rows that are not contained in the SUD,  will not colour the rows contained in the specification but not returned by the SUD.

Writing a List specification

When do we use the CollectionInterpreters

The CollectionInterpreters are used to express any kind of group, list or set of values.

When a CollectionInterpreters is executed,  compares the list of expected values with the list of values returned by the system under development. The test result depends on the specific CollectionInterpreters selected.

 offers four different CollectionInterpreters:

First row: Identification of the Collection Interpreter

As for all other interpreters, the first row of any CollectionInterpreter specifies the name of the interpreter and the name of the collection to be tested.

• Example - Provinces of Canada: A simple example would be a system containing the Canadian provinces name and code. In that particular case, we could define the collection as Canada Province Codes :

  list of

  Canada Province Codes

• Example - Phone Book : A phone book application able to manage the first name, last name and the phone number of people. The ListOfInterpreter could be express as

  list of

  phone book entries

Other rows: A set of elements

From the third row, we specify the set of values to test.

• Example - Provinces of Canada :

  list of	Canada Province Codes
  Name	Code
  ALBERTA	AB
  BRITISH COLUMBIA	AB

• Example - Phone Book :

  list of	phone book entries
  FirstName	LastName	Phone Number
  Fred	Flintstone	(123) 456-7890
  Barney	Rubble	(123) 321-7666
  Great	Gazoo	(123) 989-4455

Execution of specification

Once the developers have coded the functionality and the fixture(the fixture is the link between the system under development and the executable specification), the specification can be executed by clicking on the Execute button on the top of the page.

During execution,  will color the rows in green if the rows are in the list of elements returned by the SUD as expected in the specification.
If a row is missing or in surplus in the list returned by the SUD, then  will color the entire row in red and specify if the row is missing or in surplus.

Since the ListOfInterpreter expects to match exactly the list expected and the list returned by the SUD,  compare each cell of the table separately. If the expected value is different from the returned value,  color the cell in red and provide the two values.

Since the SupersetOfInterpreter accept that the specification may contains rows that are not contained in the SUD,  will not color the rows in the specification but not returned by the SUD.

Executable specification for the example - Provinces of Canada

Executable specification for the example - Phone Book

Creating the collection of data
We will use the DoWithInterpreter to create our personal phone book.

ListOfInterpreter : The requirement list should be the same as the SUD list.

SetOfInterpreter : The requirement set should be the same as the SUD set.

SubsetOfInterpreter : The requirement set should be a subset of the SUD set.

SupersetOfInterpreter : The requirement set should be a superset of the SUD set.