The "Define Alias" table is designed to help you to segregate requirements from the implementation.

Normally the table name must be a graceful name of the class name used in your implementation.

This might not be convenient in some situations.


Below is a dynamic decision table without any alias. This will be used in the following examples with alias definitions

ddt: add up change
# description 1c 5c 10c 25c 50c $1 total cents? $ total?
some simple addition 2 2 4 0 0 0 52 0.52


Use Case 1

The business expects a different name "add change" than your class name "add up change"

Define alias
add change add up change

ddt: add change
# description 1c 5c 10c 25c 50c $1 total cents? $ total?
some simple addition 2 2 4 0 0 1 152 1.52

Use Case 2

The business expects a different name "add up" than your class name "add up change"
and in addition the test case is defined as decision table but you implemented it as dynamic decision table.
You can overwrite the table type and the name.

Define alias
add up ddt: add up change

dt: add up
# description 1c 5c 10c 25c 50c $1 total cents? $ total?
some simple addition 2 2 4 0 1 0 102 1.02

Use Case 3

The names are matching but you need to overwrite the table type.
Note that the Define Table Type table will not overwrite type definitions given in the test.

Define alias
add up change ddt:

dt: add up change
# description 1c 5c 10c 25c 50c $1 total cents? $ total?
some simple addition 2 2 4 0 0 0 52 0.52


Use Case 4

The requirements have been written beforehand with a business name.
Your implementation requires that you prepare the test fixture in a script.

script add up change
$myfixture= get fixture

Define alias
add money $myfixture

ddt: add money
# description 1c 5c 10c 25c 50c $1 total cents? $ total?
some simple addition 2 2 4 4 0 1 252 2.52

It doesn't matters if you define the alias before or after you create the fixture.
Again you can add a table type definition if required

Define alias
add more money ddt: $anotherFixture

script add up change
$anotherFixture= get fixture

add more money
# description 1c 5c 10c 25c 50c $1 total cents? $ total?
some simple addition 2 2 4 4 0 1 252 2.52


Another example with a constructor parameter

script test query 2
show query
$tq= get fixture

Define alias
my query query: $tq

my query
n 2n
1 2
2 4

script test query 3
show query
$tq= get fixture

Define alias
my query subset query: $tq

my query
n 2n
2 4
3 6

Use Case 5

If you can't use an Import statement or you have import conflicts you can't resolve.
The alias can help you to get around these.

Define alias
what is in my pocket ddt: fitnesse.slim.test.AddUpChange


what is in my pocket
# description 1c 5c 10c 25c 50c $1 total cents? $ total?
some simple addition 2 2 4 4 0 1 252 2.52

The alias fixture allows QA people to implement requirements by reusing existing framework functions and without writing new code.
Still your test pages are easy to read, especially for project managers, BA's and Product owners who might not understand how Fitnesse works.

Hint: Try putting the "Define Alias" fixtures in the same place as your "Import" fixtures. The setup pages are a good place for these!