56 lines
2.9 KiB
Plaintext
56 lines
2.9 KiB
Plaintext
|
${fitLibrary} is specified by example by using storytests, written with ${fitLibrary} tables.
|
||
|
|
* Some of these ${storytest}/specifications are suitable for the general reader.
|
||
|
|
* Some are technical in nature, and define the finer detail of ${storytest} interpretation, such as the form of an error message
|
||
|
|
* A very few of the storytests are language specific. These are classified as being specific to Java here.
|
||
|
|
Here's an example of a specification:
|
||
|
|
!**< test
|
||
|
|
!define test (!|fitlibrary.specify.workflow.Sum|
|
||
|
|
|
||
|
|
|add|1|
|
||
|
|
|add|2|
|
||
|
|
|
||
|
|
|check|sum|3|
|
||
|
|
|
||
|
|
|check|sum|4|
|
||
|
|
)
|
||
|
|
**!
|
||
|
|
|!-fitlibrary.spec.SpecifyFixture-!|
|
||
|
|
|${test}|!-<table border="1" cellspacing="0">
|
||
|
|
<tr><td>fitlibrary.specify.workflow.Sum</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
<br><table border="1" cellspacing="0">
|
||
|
|
<tr><td>add</td>
|
||
|
|
<td>1</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td>add</td>
|
||
|
|
<td>2</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
<br><table border="1" cellspacing="0">
|
||
|
|
<tr><td>check</td>
|
||
|
|
<td>sum</td>
|
||
|
|
<td class="pass">3</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
<br><table border="1" cellspacing="0">
|
||
|
|
<tr><td>check</td>
|
||
|
|
<td>sum</td>
|
||
|
|
<td class="fail">4 <span class="fit_label">expected</span><hr>3 <span class="fit_label">actual</span></td>
|
||
|
|
</tr>
|
||
|
|
</table>-!|
|
||
|
|
|
||
|
|
The second row of the specification table contains two cells:
|
||
|
|
* The left cell holds a sequence of tables that are under test.
|
||
|
|
* The right cell holds the report that's expected from running the tables in the left cell.
|
||
|
|
* Sometimes, only some part of the error message is shown in the right, as error messages can contain programming-language-specific information.
|
||
|
|
* Sometimes two rows are used instead of two cells in a single row.
|
||
|
|
The storytest passes if the test tables and the report tables are the same (ignoring extra error information)
|
||
|
|
* The assertion count reported for the storytest is different from usual
|
||
|
|
* It is based on the number of cells in the test tables, because they are all matched between the test and report
|
||
|
|
The storytests are written in the context of underlying code:
|
||
|
|
* For most of the storytests, that code is very simple. The storytest and associated code act as a simple but reasonable example of the use of that ${fitLibrary} feature.
|
||
|
|
* Sometimes that code is engineered specifically to define unusual behaviour. For example, we specify that a ''tearDown()'' method for a Traverse is called even if an exception is thrown during table interpretation. The underlying class is tailored specifically for this, and doesn't serve as a useful example of code.
|
||
|
|
The ${storytest}s for ${fitLibrary} are in transition:
|
||
|
|
* The terminology of the specifications is changing to be organised around the role of a table, rather than the specific fixture/traverse that's used. This is consistent with the current approach in ${fitLibrary} of not using fixtures/traverses explicitly.
|
||
|
|
* The ones that use a class immediately in the package ''fitlibrary.specify'' are still to be changed. Revised and new ${storytest}s use classes in sub-packages of ''fitlibrary.specify'', such as ''fitlibrary.specify.workflow''.
|