Writing my first executable specificationWriting an executable specification for a Calculator programConsider 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 provides 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 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. Execute the specificationIf 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 exampleOnce 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 table and executes the test (no coding is needed here).
When there is an error, colors the cell in red.
Adding new specifications to our CalculatorThe business expert wants to improve the Calculator: The Calculator should be able to perform product and quotient of two numbers.
Rule Validation (Rule For)Definition
Specific Keywords for expected valuesoffers a list of useful keywords to support the Business Expert.
Coloringwill visually show the test result by coloring each testing cell:
Here is an example of cell coloring:
Writing a Rule For SpecificationWhen 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 ForIn a Rule For table, the first row specifies the name of the interpreter and the name of the rules to be tested.
Second row: the HeaderThe 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.
Third and following rows: ExamplesThe remaining rows capture the examples. They are the executable test rows. Final expression of the Division example
Final expression of the Mortgage exampleSpecification: "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 specificationsBased 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 display that no test was performed, and shows the returned value.
List Validation (List of, Set of, Superset of, Subset of)Definition
Specific keywordsNone Coloringwill visually indicate the test result by coloring the rows:
Particular behaviour for the list of interpreters: Particular behaviour for the superset of interpreters: Writing a List specificationWhen do we use the CollectionInterpretersThe 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 InterpreterAs 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.
Other rows: A set of elementsFrom the third row, we specify the set of values to test.
Execution of specificationOnce 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.
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, colors the cell in red and provides the two values. 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
Executable specification for the example - Phone BookCreating the collection of data
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.
Workflow validationDefinition
Specific Keywordsoffers a list of useful keywords to support the Business Expert. Those keywords are placed at the beginning of an action row.
coloringwill visually show the test result by coloring each testing cell:
Writing a Do With specificationWhen do we use the DoWithInterpreterThe 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. First row: Identification of the Do WithAs 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. Example of a bank Account management systemExample 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
or more simply as
Following rows: Actions & VerificationsThe second and the 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.
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:
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:
Example: Verify the balance of an accountTo verify the success of a particular action, we write the keyword "Check" prior to the first part of the action description.
Final expression of our example
Our first business rule says that a new account should have a balance of 0.00 dollars.
Our next rule says that the bank should not take any fees when we deposit money in our account.
The following rule says that a customer should be able to withdraw funds, if the balance of his account is sufficient.
Execution of specificationBased 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, will color cells in green if the execution has passed and color it in red if the execution has failed. The colored cells depends on the type of action described:
Scenario specificationDefinition
Coloringwill visually show the test result by coloring a complete row or words inside the row:
Writing a Scenario specificationWhen do we use the ScenarioInterpreterThe 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 ScenarioAs 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 systemExample 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
or more simply as
Following rows: Actions & VerificationsThe 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.
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:
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:
Example: Verify the balance of an accountIn our example, there would be two parameters: the account number and the amount of balance.
Final expression of our example
Our first business rule says that a new account should have a balance of 0.00 dollars.
Our next rule says that the bank should not take any fees when we deposit money in our account.
The following rule says that a customer should be able to withdraw funds if the balance of his account is sufficient.
Execution of specificationBased 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, will color rows or words inside a row in green if the execution has passed and color it in red if the execution has failed.
6. Context definition (Setup)Definition
Coloringwill visually show the test result by coloring each testing cell:
Writing a Setup specificationWhen do we use the SetUpInterpreterThe 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. First row: Identification of the Set UpAs 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 systemExample 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
Second row: the HeaderThe 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.
Following rows: DataThe remaining rows capture the data, which is meant to be inserted. They are the executable rows. Final expression of our example
From that point, we can now used those accounts to specify examples that define a business rule.
Transfer from a savings account to a checking account of the same customer
Execution of specificationBased 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, confirms that the value has been entered by adding a green cell at the end of each data rows containing the word entered. If the data could not have been entered, because it does not respect a known business rule, the cell will be yellow and will specify the stacktrace. Finally, if the data could not be entered, because of an unknown error, will add a yellow cell at the end of the row containing information about the exception. Note that if the error is specific to a data provided, will color this specific cell yellow and will include the information about the exception.
AdvancedDo With - Table, Bullet List or Number List examplesupports 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 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
Bullet List
Number List
Object-Graph Navigation Language (OGNL)has an extension to supports OGNL expressions. Here are some examples, using the Calculator system:
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. Information TagInformation tagsWhen a document is executable, will try to interpret all the supported forms of the document body. To avoid undesired interpretation of forms, we can use the Information tags. Here is an example:
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.
Commented formsComment tagIf necessary, we can decide that a test shouldn't be executed. Instead of deleting the test from the document, we can comment it. This will force to skip the test. The test should be preceded by the tag Comment. Here are some examples: Test using the bullet list form.
Test using the Table form.
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.
|