Excerpt | ||||
---|---|---|---|---|
|
Note | ||
---|---|---|
| ||
The following executable tables are designed with a header row of 2 columns. This is just design. You can create tables with e.g. 3x3 cells. |
...
In order to be executable in , the specification must be expressed in a specific form :
Decision Table | Calculator | |
x | y | sum? |
6 | 3 | 9 |
The first line of the specification explains that we have particular RULES FOR our Calculator. The calculator receives two numbers and gives back the sum of those two numbers. Once the calculator is developed, we will be able to execute the specification to test the functionality.
...
Once the Calculator is developed, the business expert may think about new examples that he would like to test. The business expert adds another row in the Rule For Decision Table table and executes the test (no coding is needed here).
Decision Table | Calculator | |
x | y | sum? |
6 | 3 | 9 |
7 | 0 | 8 |
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.
...
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 expected errors, the keyword error may be used in order to test those special cases.
Decision Table | Calculator | |||
x | y | sum? | product? | quotient? |
6 | 2 | 8 | 12 | 3 |
7 | 0 | 7 | 0 | error |
Rule Validation (
...
Decision Table)
Definition
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
The RuleForInterpreter is used to express concrete and measurable business rules.
|
...
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:
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
When the expected value matches the returned value, the RuleForInterpreter colors the cell as "right" by coloring it green. |
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
If the values don't match, the RuleForInterpreter colors the cell as "wrong" in red. |
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
If the system encounters an execution error, the cell is colored yellow and provides information about the error. |
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
If no expected value is specified in a test, the RuleForInterpreter colors the cell in gray. |
...
Here is an example of cell coloring:
Input Table:
Decision Table | Calculator |
---|
x | y | sum? | product() | quotient? |
10 | 0 | 10 | 0 | 0 |
6 | 3 | 9 | -5 |
Output Table:
Decision Table | Calculcator |
---|
x | y | sum? | product() | quotient? |
10 | 0 | 10 | 0 | 0 java.lang.ArithmeticException: / by zero |
6 | 3 | 9 | Expected: -5 Received: 18 | 2 |
Writing a
...
Decision Table Specification
When do we use the RuleForInterpreter?
...
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
...
Decision Table
In a Rule For Decision Table 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 forDecision Table 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 forDecision Table 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 forDecision Table 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 forDecision Table insurance premium fee calculation sale price down payment premium fee?
Third and following rows: Examples
...
Final expression of the Division example
Decision Table | Division | |
dividend | divisor | quotient? |
6.0 | 2.0 | 3.0 |
7 | 2 | 3.5 |
18 | 3.0 | 6 |
15 | 2 | 8 |
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)."
Decision Table | insurance premium fee calculation | |
sale price | down payment | premium fee? |
$100,000 | $15,000 | $2,125.00 |
$100,000 | $30,000 | $0.00 |
$100,000 | $25,000 | $0.00 |
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.
Decision Table | insurance premium fee calculation | ||
sale price | down payment | premium fee? | financed amount? |
$100,000 | $15,000 | $2,125.00 |
$100,000 | $30,000 | $0.00 |
$100,000 | $25,000 | $0.00 |
Execution of specifications
...
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
The collection interpreters are used to express any kind of groups, lists or sets of values. When a collection interpreter is executed, compares the list of values expected with the list of values returned by the system under development. The test result depends on the specific collection interpreter selected.
|
...
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
As expected, the row is returned by the system under development. |
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
A row is missing or in surplus in the list returned by the system under development. |
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
If the system encounters an execution error, the cell is colored in yellow, and provides information about the error. |
...
offers four different CollectionInterpreters:
ListOfInterpreter | This interpreter expects to match the content and the order of the list returned by the system under development (SUD) with the expected list defined in the specification. | A is a subset of B |
---|---|---|
SetOfInterpreter | The SetOfInterpreter expects to match only the content of the list returned by the SUD with the expected list defined in the specification. The order of the rows is not important. | |
SubsetOfInterpreter | The SubsetOfInterpreter verifies that each row defined in the specification exists in the list returned by the SUD. In order to have a successful test, the set of elements listed in the specification should be a subset of the list returned by the SUD. | |
SupersetOfInterpreter | The SupersetOfInterpreter verifies that each row returned by the SUD exists in the list defined in the specification. In order to have a successful test, the set of elements listed in the specification should be a superset of the list returned by the SUD. This means that the specification may contain rows that are not contained in the SUD. |
First row: Identification of the Collection Interpreter
...
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 expressed as :
list of
phone book entries
Other rows: A set of elements
...
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
...
Since the SupersetOfInterpreter accepts that the specification may contain rows that are not contained in the SUD, will not color the rows, which are contained in the specification but not returned by the SUD.
Executable specification for the example - Provinces of Canada
list of | Canada Province Codes |
Name | Code |
ALBERTA | AB |
BRITISH COLUMBIA | BC |
MANITOBA | MB |
NEW BRUNSWICK | NB |
NEWFOUNDLAND and LABRADOR | NL |
NOVA SCOTIA | NS |
NUNAVUT | NU |
ONTARIO | ON |
PRINCE EDWARD ISLAND | PE |
QUEBEC | QC |
SASKATCHEWAN | SK |
YUKON | YT |
OTHER PROVINCE | OP |
Executable specification for the example - Phone Book
Creating the collection of data
We will use the DoWithInterpreter to create our personal phone book.
Workflow | phone book |
insert | Fred |
Flintstone | with number | (123) 456-7890 | ||
insert | Barney |
Rubble | with number | (123) 321-7666 | |
insert | Great |
Gazoo | with number | (123) 989-4455 |
ListOfInterpreter : The requirement list should be the same as the SUD list.
list of | Phone book entries |
FirstName | LastName |
Fred | Flintstone |
Betty | Rubble |
Great | Gazoo |
Wilma | Flintstone |
SetOfInterpreter : The requirement set should be the same as the SUD set.
set of | Phone book entries |
FirstName | LastName |
Fred | Flintstone |
Betty | Rubble |
Great | Gazoo |
Wilma | Flintstone |
SubsetOfInterpreter : The requirement set should be a subset of the SUD set.
subset of | Phone book entries |
FirstName | LastName |
Fred | Flintstone |
Betty | Rubble |
Great | Gazoo |
Wilma | Flintstone |
SupersetOfInterpreter : The requirement set should be a superset of the SUD set.
superset of | Phone book entries |
FirstName | LastName |
Fred | Flintstone |
Betty | Rubble |
Great | Gazoo |
Wilma | Flintstone |
Info |
---|
The examples provided in this page are used to explain how to write the fixture for the CollectionInterpreters. |
...
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
The DoWithInterpreter 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, confirms that each action has successfully been performed.
|
...
offers a list of useful keywords to support the Business Expert. Those keywords are placed at the beginning of an action row.
Accept | Confirm that the action has been executed by the system under development. |
---|---|
Check | Verify the specified expected value with the value returned by the system under development |
Reject | The action should not be performed by the system under development (expected errors). |
Display | Print the value returned by the system under development. |
coloring
will visually show the test result by coloring each testing cell:
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
When the action has been executed successfully, colors the cell(s) in green. |
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
If the action execution has failed, colors the cell(s) in red. |
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
If the system encounters an execution error, the cell is colored yellow and provides information about the error. |
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
When the action has been executed successfully, will display the returned value in gray. |
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 the case of a failure, 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 a
...
Workflow specification
When do we use the DoWithInterpreter
...
When a sequence of action is executed, confirms that each action has successfully been performed.
First row: Identification of the
...
Workflow
As for all other interpreters, the first row of the DoWithInterpreter 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 defined before any sequence of actions.
...
So the first line could be expressed as
Workflow | bank account management |
or more simply as
Workflow | bank |
Following rows: Actions & Verifications
...
Info | |||||||
---|---|---|---|---|---|---|---|
The form of each row of a DoWithInterpreter must follow these rules:
More visually:
|
Example: In our bank example, the first action would be to create a bank account.
If we want to take the account number as a parameter, we would have:
open checking account | 12345-67890 |
But, if we want to consider the type of account, the account number, the owner first name and last name as parameters, we would have:
open | checking | account | 12345-67890 | under the name of | Spongebob |
Squarepants |
Example: Verify the balance of an account
To verify the success of a particular action, we write the keyword "Check" prior to the first part of the action description.
In our example, there would be two parameters: the account number and the amount of balance.
check | that balance of account | 12345-67890 | is | $0.00 |
Final expression of our example
Workflow | bank |
Our first business rule says that a new account should have a balance of 0.00 dollars.
open | checking | account | 12345-67890 | under the name of | Spongebob |
Squarepants | ||||
check | that balance of account | 12345-67890 | is | $0.00 |
Our next rule says that the bank should not take any fees when we deposit money in our account.
deposit | $100.00 | in account | 12345-67890 | |
check | that balance of account | 12345-67890 | is | $100.00 |
The following rule says that a customer should be able to withdraw funds, if the balance of his account is sufficient.
withdraw | $50.00 | from account | 12345-67890 | |
check | that balance of account | 12345-67890 | is | $50.00 |
reject | withdraw | $75.00 | from account | 12345-67890 |
check | that balance of account | 12345-67890 | is | $50.00 |
accept | withdraw | $25.00 | from account | 12345-67890 |
Execution of specification
...
Info |
---|
The examples provided in this page are used to explain how to write the fixture for the DoWithInterpreter. |
Scenario specification
Definition
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
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. When a sequence of action is executed, confirms that each action has successfully been performed.
|
Coloring
will visually show the test result by coloring a complete row or words inside the row:
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
When the action has been executed successfully, colors the row or words inside the row in green. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
If the action execution has failed, colors the the row or words inside the row in red. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
If the system encounters an execution error, the row is colored yellow and provides information about the error. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
When the action has been executed successfully, will display the returned value in gray. |
Writing a Scenario specification
When do we use the ScenarioInterpreter
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.
When a sequence of action is executed, confirms that each action has successfully been performed.
First row: Identification of the Scenario
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 has to be defined once for all the sequences of actions expressed in a page. Obviously, the ScenarioInterpreter must be defined before any sequence of actions.
Example of a bank Account management system
Example context : The system under development must be able to manage two different types of bank account. The system should allow to execute the usual transactions within an account.
So the first line could be expressed as
scenario | bank account management |
or more simply as
scenario | bank |
Following rows: Actions & Verifications
The second and following rows are used to express specific actions or verifications. The business expert should express the action in human readable format rather than using computer like language.
Info |
---|
With this interpreter, only 1 cell is required to express the action (in comparison to the DoWithInterpreter). |
Example: In our bank example, the first action would be to create a bank account .
If we want to take the account number as a parameter, we would have:
open checking account 12345-67890 |
But, if we want to consider the type of account, the account number, the owner first name and last name as parameters, we would have:
open checking account 12345-67890 under the name of Spongebob Squarepants |
Example: Verify the balance of an account
In our example, there would be two parameters: the account number and the amount of balance.
verify that balance of account 12345-67890 is $0.00 |
Final expression of our example
scenario | bank |
Our first business rule says that a new account should have a balance of 0.00 dollars.
open checking account 12345-67890 under the name of Spongebob Squarepants |
verify that balance of account 12345-67890 is $0.00 |
Our next rule says that the bank should not take any fees when we deposit money in our account.
deposit $100.00 in account 12345-67890 |
verify that balance of account 12345-67890 is $100.00 |
The following rule says that a customer should be able to withdraw funds if the balance of his account is sufficient.
...
Execution of specification
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.
...
6. Context definition (Setup)
Definition
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
The SetUpInterpreter is used to simplify the creation of a particular state for the system under development. Once the state is created, we can focus on the business process to test. When a setup table is executed, enters data in the system under development to create the desired state.
|
Coloring
will visually show the test result by coloring each testing cell:
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
When the insertion has been executed successfully, adds a green cell at the end of the data row with the word entered. |
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
If the insertion has failed because the values specified does not respect a business rule, adds a red cell at the end of the row with the word not entered. |
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
If the insertion has failed because a specified value generates an error, colors the cell of the data in error yellow and provides information about the error. |
...
As for all other interpreters, the first row of the setup table specifies the name of the interpreter and the name of the desired state.
Example of a bank Account management system
Example context : A customer should be allowed to transfer money from his or her accounts.
In order to create examples that would test this particular business rule, we need to create a set of customer. The first line of our setup table could be expressed as
setup | a group of customers |
Second row: the Header
The second row is called the header row and serves to identify the data to be inserted in the system under development.
Example: In our bank example, the header row could take the following form.
setup | a group of customers | |||
type | number | first name | last name | balance |
Following rows: Data
The remaining rows capture the data, which is meant to be inserted. They are the executable rows.
Final expression of our example
setup | a group of customers | |||
type | number | first name | last name | balance |
checking | 11111-11111 | Fred | Flintstone | $250.00 |
savings | 22222-22222 | Fred | Flintstone | $10 000.00 |
savings | 44444-44444 | Wilma | Flintstone | $10 000.00 |
checking | 44444-44444 | Barney | Rubble | $999.54 |
checking | 55555-55555 | Great | Gazoo | abc |
From that point, we can now used those accounts to specify examples that define a business rule.
Workflow | bank |
Transfer from a savings account to a checking account of the same customer
accept | Transfer | $1 000.00 | from account | 22222-22222 | to account | 11111-11111 |
check | that balance of account | 11111-11111 | is | $1 250.00 | ||
check | that balance of account | 22222-22222 | is | $9 000.00 |
Execution of specification
...
Info |
---|
The examples provided in this page are used to explain how to write the fixture for the SetupInterpreter. |
Advanced
...
Workflow - Table, Bullet List or Number List example
supports the expression of rules in table format, bullet list format or number list format. The following examples are equivalent and will yield the same results when executed.
It is important to note that the table and bullet list examples are not executable, since the import info.novatec.testit.livingdoc.samples.fixture.bank and do with Workflow bank rules cannot be specified twice in the same page. Even though it is possible to change between the two methods in the same page, you must keep in mind that the tests are executed in the same system under development. So it is not necessary to re-specify the same rule in the page.
Table
import |
info.novatec.testit.livingdoc.samples.application.bank |
Workflow | bank | ||||
open | checking | account | 12345-67890 | under the name of | Spongebob |
Squarepants | ||||
check | that balance of account | 12345-67890 | is | $0.00 |
deposit | $100.00 | in account | 12345-67890 | |
check | that balance of account | 12345-67890 | is | $100.00 |
Bullet List
- import
- info.novatec.testit.livingdoc.samples.application.bank
- do withWorkflow bank
- open checking account 12345-67890 under the name of Spongebob _Squarepants
- deposit $100.00 in account 12345-67890
- check that balance of account 12345-67890 is $100.00
...
- import
- info.novatec.testit.livingdoc.samples.application.bank
- Workflow
...
- do with bank
- open checking account 12345-67890 under the name of Spongebob _Squarepants
- deposit $100.00 in account 12345-67890
- check that balance of account 12345-67890 is $100.00
...
has an extension to supports OGNL expressions. Here are some examples, using the Calculator system:
< , <= , > , >= , and , or | supports these simple mathematical expressions. Use the question mark to specify the position of the value returned by the system. For example, if the expected value should be greater than 15, you would write "? > 15" in the cell. |
---|---|
+ , - , / , * | performs simple operations as a resulting expression. To specify you want to evaluate those operations prior to the comparison, insert an equal sign at the beginning of the operation (ex: =4+1-3). |
Decision Table | calculator | |||
x | y | sum? | product? | quotient? |
6 | 2 | 8 | 12 | 3 |
7 | 0 | 7 | 0 | error |
40 | 50 | 90 | ? > 100 |
4 | -5 | ? <= 0 | -20 | ? <= 0 |
3 | 3 | ? < 1 or ? > 4 | ? >= 9 and ? < 12 | "1" |
4 | 2 | =4+2-0 | =2*4 | =4/2 |
To use this extension, you need to specify the fixture factory as info.novatec.testit.livingdoc.extensions.ognl.OgnlSupport and add the livingdoc-extensions-ognl-x.x.jar and ognl-x.x.x.jar to the classpath of the SUT.
...
To avoid undesired interpretation of forms, we can use the Information tags.
This tag will force to skip all forms between the Begin Info and End Info tags.
Here is an example:
Begin Info |
This table | shouldn't be | interpreted |
- This bullet list
- shouldn't be
- interpreted either
End Info |
We won't see any coloration of the above table or bullet list after execution of this document.
will restart the interpretation of the document from from this point.
Decision Table | Calculator | |
---|---|---|
x | y | sum? |
1 | 2 | 3 |
Info | ||
---|---|---|
| ||
If the End Info tag is omitted all the body content of the document after the Begin Info tag, will be skipped. |
...
Test using the Table form.
Comment | |
My table | to skip |
We won't see any coloration of the above table or bullet list after execution of this document.
will restart the interpretation of the document from from this point.
Decision Table | Calculator | |
---|---|---|
x | y | sum? |
1 | 2 | 3 |