Hardware Reference
In-Depth Information
not have any authoring features directly supporting the task domain. Existing
tools that support either FIT or FitNesse include AutAT and FitClipse. Au-
tAT seeks to assist “business-side people” taking a visual approach to building
Acceptance Tests [32]. As FitClipse [33] builds on FitNesse tests are entered
using its wiki syntax. Mugridge introduces a process based around a library of
fixtures named FitLibrary, which improves FIT's “business-level expressiveness”
to emphasise a “domain-driven design approach” [34]. It supports a type of fix-
ture, DoFixtures , which approach natural language in readability. Commercial
software also supports such a workflow, with GreenPepper [35] supporting “ex-
ecutable specifications” while providing an expressive library of table types. For
clarity, it is important to note that GreenPepper uses code annotations (Java
and C#) that are unrelated to the annotations in this paper. However, none of
these tools is focused on reusing existing documentation, so unlike the proposed
approach these approaches require re-writes of content.
In the requirements authoring process, Melnik and Maurer found that the use
of FIT helped students to “learn how express requirements in a precise, unequiv-
ocal manner” [36]. In a number of experiments aimed at evaluating the impact
of FIT tables on the implementation of change requests Ricca et al. [37], found
improvement in the correctness of code produced. The addition of FIT Tables
to plain text descriptions had the most impact on more experienced students,
and they found no significant increase in time taken to implement the changes.
The use of annotations was proposed because it provides users with a simple
conceptual framework allowing them to add detail to text descriptions of tests.
Annotations are used here to allow for links to be made between descriptions and
corresponding FIT Tables. These annotations are based on elements of an ac-
ceptance test description recommended by Jain [29]. There are four basic types,
covering most elements of an individual acceptance test:
- Precondition : event that must occur before a test is run.
- Actor + Action : part of system and functionality.
- Observerable Result : a verifiable response generated by the system.
- Examples : represent the input data given to a test.
The passing or failure of a test rests with variance from specified Observable
Results . A visual representation of the annotations is contained in Figure 1.
Fig. 1. Annotations
Search WWH ::




Custom Search