
FitNesseRoot.Fitnesse.SuiteFitAcceptanceTests.TestFixtures.content.txt Maven / Gradle / Ivy
!-
Fit Specification: Fixtures
Fit doc uments are owned by the c ustomers
and domain experts on your team. The doc uments
c ontain examples of how the program should
work and Fit c hec ks
the examples against the ac tual program. The examples are plac ed
in tables with a spec ial first row, but other
than that, there are no limitations on how the examples are struc tured. Customers should write tables in the way that
c omes most naturally to them.
Sinc e there arent any limits to the way
tables are struc tured, Fit c ant
interpret the tables automatic ally. It requires a fixture to interpret the
table. A fixture is a piec e
of c ode, written by the teams programmers,
that understands the struc ture of eac h
type of table and how to c hec k
it against the ac tual program.
Contents:
Comparison
Values Convert to HTML
Loading Fixtures
The first row of a table is always the name of the fixture used to interpret
that table. Theres no spec ial
logic applied; if the first c ell
in the first row is not the c orrec t
fixture name, Fit wont try to guess where it is. (Note: we use the keyword (missing) to indic ate
a missing fixture name in the table below.)
fat.FixtureNameFixture
Table
FixtureName()
[exampleFixture]
exampleFixture
[exampleFixture]
[1] [2]
[3] [4]
exampleFixture
[] [exampleFixture]
(missing)
[exampleFixture] [foo]
exampleFixture
[]
[exampleFixture]
(missing)
The fixture name is the full name of the c ode
that will interpret the table. (In Java,
its a c lass.)
The fixture name is c ase sensitive and
must be fully qualified (that is, inc lude any
namespac e information). All implementations of Fit use the dot
notation of Java to qualify names.
fat.FixtureLoadFixture
FixtureName
LoadResult()
fat.ExampleFixture
loaded
fat.exampleFixture
error
Fat.ExampleFixture
error
ExampleFixture
error
fat.Example
error
Errors
When the fixture isnt valid, Fit annotates the c ell
with an explanatory error message. What
makes something a fixture or not depends on whic h
implementation of Fit youre using. In
Java, for example, only c lasses that extend
the Fixture c lass are fixtures. Other languages might use the presenc e
of spec ific
methods to determine whether something is a fixture or not.
This error message may be displayed as part of additional information, suc h
as an exc eption stac k
trac e.
fat.FixtureLoadFixture
FixtureName
LoadResult()
ErrorMessage()
fat.ExampleFixture
loaded
(none)
NoSuc hFixture
error
The fixture
"NoSuc hFixture" was not found.
fat.NotAFixture
error
"fat.NotAFixture
was found, but its not a fixture.
Case-sensitivity errors use the same error message as other not found
errors.
fat.FixtureLoadFixture
FixtureName
LoadResult()
ErrorMessage()
fat.exampleFixture
error
The fixture "fat.exampleFixture" was not found.
NOTE TO IMPLEMENTORS:
The remainder of this doc ument is inc omplete. The above examples should pass. Dont try to make any of the following
examples pass, as they will surely change.
Interpreting Tables
By default, fixtures interpret tables from left to right and top to bottom.
fat.InterpretationOrderFixture
Table
InterpretationOrder()
[fat.Conc atenateFixture]
[top left] [top middle] [top right]
[bottom left] [bottom middle] [bottom right]
top left, top middle, top right, bottom left, bottom middle, bottom right
Although left-to-right and top-to-bottom is the default, fixtures may
interpret tables in any order they please.
The fixture in the following example interprets tables c olumn
by c olumn, from right to left and top to
bottom.
fat.InterpretationOrderFixture
Table
InterpretationOrder()
[fat.ReverseConc atenateFixture]
[top left] [top middle] [top right]
[bottom left] [bottom middle] [bottom right]
top right, bottom right, top middle, bottom middle, top left, bottom left
Default Interpretation
Fits default interpretation of a c ell
is to mark it with the ignore standard annotation. (See the annotation
specification for details about standard annotations.)
fat.InterpreterFixture
InputTable
InterpretedTable()
RenderedOutput()
[fat.DoNothingFixture]
[left] [right]
<table>
<tr><td>fat.DoNothingFixture</td></tr>
<tr><td bgc olor="#efefef">left</td><td
bgc olor="#efefef">right</td></tr>
</table>
If an error oc c urs
while interpreting a c ell, Fit marks it with
the error annotation and inc ludes whatever
error information is available. (In
Java, this is a stac k trac e.)
??
Fixtures may override the default interpretation and do whatever they
wish. The fixture in the following
example marks all c ells with the right
standard annotation unless an error oc c urs,
in whic h c ase
it is marked with the ignore standard annotation.
??
Chec king
Cells
Fit provides a standard servic e
for c hec king
a table c ells c orrec tness. Given a table c ell
and a value, Fit c ompares the two and annotates
the c ell ac c ordingly. (This sec tion
assumes that the c omparison value is a
string. See Type Conversion, below,
for information about what happens when its not.)
Right and Wrong
When the table c ell and the
c omparison value matc h,
Fit marks the c ell right using a standard
annotation. (See the annotation specification for more about standard
annotations.)
fat.Chec kFixture
Cell
ComparisonValue
Annotation()
<td>Something</td>
Something
right
When they dont matc h, Fit
marks the c ell wrong and inc ludes
the c omparison value.
fat.Chec kFixture
Cell
ComparisonValue
Annotation()
Expec ted()
Ac tual()
<td>Something</td>
Something else
wrong
Something
Something else
Empty Cells
If the table c ell is empty,
Fit uses the info standard annotation to put the c omparison
value in the c ell.
fat.Chec kFixture
Cell
ComparisonValue
Annotation()
Info()
<td></td>
Anything
info
Anything
Unexpec ted
Errors
If an error oc c urs
while c omparing the table c ell
to the fixtures value, Fit uses the error standard annotation to put
information about the error into the table.
If a stac k trac e
or similar information is available, it is inc luded.
The following examples use the keyword (c auses
error) in the ComparisonValue c olumn to
indic ate that an error oc c urs.
fat.Chec kFixture
Cell
ComparisonValue
Annotation()
<td>something</td>
(c auses error)
error
If the table c ell is empty,
Fit uses the info standard annotation to put the word error into the
table. No error information (suc h
as a stac k trac e)
is inc luded.
fat.Chec kFixture
Cell
ComparisonValue
Annotation()
Info()
<td></td>
(c auses error)
info
error
Expec ted
Errors
If the table c ell c ontains
the word error, Fit assumes that an error was expec ted. If an error oc c urs,
Fit marks the c ell right. If it doesnt, Fit marks the c ell
wrong.
fat.Chec kFixture
Cell
ComparisonValue
Annotation()
Expec ted()
Ac tual()
<td>error</td>
(c auses error)
right
n/a
n/a
<td>error</td>
Anything
wrong
error
Anything
Expec ted
Blank
Fit does not support
a standard blank keyword similar to the error keyword. (Although the following example uses a
(blank) keyword to indic ate a blank c omparison
value, this keyword was programmed as part of fat.Chec kFixture
and is not a standard part of Fit.)
fat.Chec kFixture
Cell
ComparisonValue
Annotation()
Expec ted()
Ac tual()
Info()
<td>blank</td>
(blank)
wrong
blank
(blank)
n/a
<td>blank</td>
Anything
wrong
blank
Anything
n/a
<td></td>
(blank)
info
n/a
n/a
(blank)
<td></td>
Anything
info
n/a
n/a
Anything
If a fixture wishes to allow blank values, it must handle
this on its own. A c ommon
approac h is for the fixture to look for blank
results and to c onvert them into a spec ial
keyword, suc h as (blank) or (none). Use this keyword in the table when a blank
result is expec ted.
Cell HTML Converts to Text
The c ontents of the c ell
are c onverted from HTML to text as desc ribed
in the parsing specification.
fat.Chec kFixture
Cell
ComparisonValue
Annotation()
Expec ted()
Ac tual()
<td><i>anything</i></td>
anything
right
n/a
n/a
<td><i>anything</i></td>
<i>anything</i>
wrong
anything
<i>anything</i>
<td><i>anything</i></td>
<i>anything</i>
right
n/a
n/a
<td><i>anything</i></td>
anything
wrong
<i>anything</i>
anything
This c onversion applies to
blank c ells and the error keyword as well.
fat.Chec kFixture
Cell
ComparisonValue
Annotation()
Info()
<td> </td>
anything
info
anything
<td><font c olor="red">error</font></td>
(c auses error)
right
n/a
Comparison Values Convert to HTML
When a c omparison value is
used in an annotation, its c onverted to HTML
as desc ribed in the annotations
specification. See that section for
examples.
Type Conversion
(to do)
Converting strings to objec ts
Converting objec ts to strings
Comparing objec ts
Predefined Fixtures
Fit inc ludes several predefined
fixtures. Eac h
fixture is desc ribed in a separate doc ument,
shown in the table below.
fat.Referenc eFixture
Desc ription
Loc ation
Result()
Primitive Fixture
primitive-fixture.html
Column Fixture
c olumn-fixture.html
Row Fixture
row-fixture.html
Ac tion Fixture
ac tion-fixture.html
Summary Fixture
summary-fixture.html
Run Results
fit.Summary
(to do)
Be sure to inc lude right, wrong, exc eption,
and ignore c ounts in c hec k
disc ussion
Chec k
Expec ted values spec ified
in c ells are tested for equality with ac tual
values extrac ted from the program under test.
fat.Equals
type
x
y
=
boolean
true
TRUE
true
integer
00001
1
true
real
1000
1e3
true
string
abc
ABC
false
string
a b c
a b c
true
A sequenc e of values c an
be entered and c hec ked
as a single (c omposite) value.
fat.Equals
type
x
y
=
integers
1, 3, 5
01,03,05
true
integers
1, 3, 5
01,05,03
false
booleans
true, true, false
true, false
false
strings
a , b , c
a,b,c
true
Domain values c an be c onstruc ted
from c ell c ontents.
Equality c omparisons will be subjec t
to appropriate domain rules (i.e. delegated to the domain objec ts.)
fat.Equals
type
x
y
=
date
Jan 1, 1995
January 1, 1995
true
money
$10000
$10,000.00
true
Floating point numbers are c hec ked
to the prec ision that is normal in the host
language. It is possible for a domain objec t
to infer prec ision from the string
representation of expec ted values. For
example, [?]Sc ientific Double
c hec ks
equality to the prec ision implied by the
number of signific ant digits in a value.
·
non-zeros -- 123.45 is 5 digits
·
zeros between non-zeros -- 100003 is 6 digits
·
zeros in the frac tion
part -- 12.20 is 4 digits
·
but not leading zeros -- 0001000 is 4 digits
·
and not exponent digits -- 6.02e23 is 3 digits
·
left argument (rec eiver)
c ontroles prec ision
fat.Equals
type
x
y
=
real
123.45
123.449
false
sc ientific
123.45
123.449
true
sc ientific
100003
100003.1
true
sc ientific
100003.1
100003
false
sc ientific
12.20
12.210
false
sc ientific
12.21
12.210
true
Improperly spec ified values may throw exc eptions
whic h are reported in the c ell
that c ontains the invalid number. Improper
value detec tion is only as good as would be
expec ted in the host language. (We are
assuming that inc orrec tly
c onverted values will lead to detec ted
errors elsewhere.)
·
xyz is not an integer
·
10000000000000000000000000 may or may not be an
integer
fat.Table
fat.Equals
type
x
integer
200
integer
xyz
fat.Color
white
white
white
white
white
white
white
yellow
Some c harac ter
strings have spec ial meaning outside of type c onversion.
·
blank -- omit c hec k,
report value (reported in gray letters)
·
error -- expec t
an error
fat.Table
fat.Divide
x
y
divide()
100
2
50
100
2
100
0
error
100
0
fat.Color
white
white
white
white
white
white
white
white
green
white
white
gray/white
white
white
green
white
white
gray/white
The framework looks for parse support in different plac es.
·
fixture
·
domain objec t
·
type adapter
The framework will allow fixtures to implement c ustom
parsing.
·
yea = true
·
nay = false
Fixture
By default c ells are proc essed
in order, by table, by row within tables, and by c ell
within rows. Distinc t routines handle sequenc ing
(plural) and interpretation (singular).
·
doTables -- sequenc e
tables within a doc ument
·
doTable -- interpret a table
·
doRows -- sequenc e
rows within a table
·
doRow -- interpret a row
·
doCells -- sequenc e
c ells within a row
·
doCell -- interpret a row
The default interpretation of a c ell is to
mark it as ignored.
Cells c ontain givens or expec ted
results. The fixture is responsible for distinguishing givens from expec ted
results, c hec king
expec ted results against ac tuals,
and indic ating the result with the bac kground
annotation as follows.
·
white -- no c hec k
wanted (blank input)
·
green -- right: expec ted
equals ac tual
·
red -- wrong: expec ted
not equal ac tual
·
yellow -- exc eption:
trouble c omputing ac tual
or c omparing result
·
gray -- ignore: desired c hec k
not possible
Fixtures c ooperate to c ount
the number of eac h result.
·
c ounts ac c umulate
between tables
·
c ounts are
summarized as "# right, # wrong, # exc eptions,
# ignores".
·
runner fixtures (e.g. AllFiles) c an
c ontrol ac c umulation
of c ounts
Fixtures c ooperate to ac c umulate
state that c an be summarized at any point in
the proc essing of a doc ument.
·
state variables
·
state lifetime
·
state summary
The primitive fixture does not depend on TypeAdapter. Type spec ific
func tions handle all c hec king.
·
c hec kBoolean
·
c hec kInteger
·
c hec kFloat
·
c hec kString
A c olumn fixture distinguishes givens from
expec ted values by the form of the c olumn
head.
·
name is setter or field
·
name() is getter or field
·
c amel c ase
-- present value ( ) = presentValue()
·
deprec ate exec ute()
A row fixture expec ts all rows to be expec ted
values. The fixture is assumed to have ac c ess
to ac tual rows whic h
it pairs with expec ted rows.
·
name is field or getter
·
name() is getter
·
c amel c ase
Rows are matc hed by c omparing
just enough values from the left most c olumns
to get a unique matc h.
·
some given, none ac tual
-- missing row
·
none given, some ac tual
-- surplus rows
·
one given, one ac tual
-- c hec k
remaining c olumns
·
many given, many ac tual
-- matc h on more c olumns
Missing and surplus rows are marked as suc h
in their first c olumn
·
eac h c ounts
as one wrong
·
surplus rows added to table in gray
An ac tion fixture distinguishes given from
expec ted values based on keywords in the first
c olumn.
·
enter -- put given in setter or field
·
c hec k
-- c hec k
value with getter or field
·
press -- c all ac tion
(no c hec k
other than for exec ptions)
·
start -- new ac tor
An ac tor represents some interfac e
state suc h as the c urrently
ac tive window. The ac tor
gives meaning to many of the words in the sec ond
c olumn (field to be entered and buttons to be
pressed).
·
ac tor persists
between tables
·
initial ac tor
is ac tion fixture (subc lass)
itself
·
start with no argument spec ifies
initial ac tor
Start c ould have various meanings depending
on the nature of the interfac e being modeled.
·
c reate a new ac tor
·
return to an existing ac tor
Other ac tions, like press, c an
c hange the c urrent
ac tor.
·
replac e the c urrent
ac tor with a new ac tor
·
replac e the c urrent
ac tor with another preexisting ac tor
·
restore the previous ac tor
Subc lasses of ac tion
fixture c an add new ac tion
words.
·
c amel c ase
Runner
A runner c reates top-level Fixtures and
provides them with parsed doc uments to be
annotated.
·
top-level fixture is instanc e
of Fixture
A runner retrieves and disposes of doc uments
as appropriate to its environment. The FileRunner reads and
writes html files.
·
input-file only -- default output
·
input-file output-file -- spec ific
output
·
input-direc tory
only -- default output in direc tory
·
input-direc tory
output-direc tory -- default outputs in spec ific
direc tory
·
index.html result summaries
·
- is standard in/out
A runner signals the presenc e of errors to
its environment so that subsequent proc essing c an
be triggered.
·
exit status is sum of wrong and exc eptions
up to 255
·
main is fac tored
to simplify [?]RunnerFixtures
A runner establishes run spec ific
state that may influenc e loading and/or c onfiguration
of the program under test.
·
[?]AssemblyPath ???
-!
© 2015 - 2025 Weber Informatics LLC | Privacy Policy