16 lines
1.6 KiB
Plaintext
16 lines
1.6 KiB
Plaintext
An ${entity} will always have a ${key}, that makes it unique from every other ${entity}. There are various potential traps in basing the ${key} on the properties of an ${entity}. So, often, an ''internal'' key is auto-generated by the database. This is often called an ''id''.
|
|
|
|
In the following, we consider how to handle an ${entity} that has an internal key.
|
|
|
|
An internal key will not normally be visible in a ${storytest}. So how do we refer to a specific ${entity}? Here are two approaches:
|
|
* The approach used in the ${fitNesse} version of ${fit}
|
|
* The approach used in ${fitLibrary}
|
|
!3 ${fitNesse} Approach
|
|
In the ${fitNesse}version of ${fit}, there is a special mechanism for holding internal keys in ''variables'' so that they can be referred to later. The labels in the header rows of setup and checking tables have special annotations that introduce and use variable names.
|
|
|
|
This works fine where only setup and checking tables are being used. However, if an ${entity} is created and/or referenced in ${workflow}, there is no obvious mechanism. Likewise if an ${entity} reference occurs in a property of an object (or element of a collection) that's handled as a nested table.
|
|
!3 ${fitLibrary} approach
|
|
In this approach, we assume that the entities in a particular storytest are distinct in some way in one or more of their property values. Then those properties can be used to refer to an ${entity}, as a ''pseudo-''${key}.
|
|
* Such a ${key} is handled as a String.
|
|
* An associated ${finder} is specified that takes the String and looks up the ${entity} that's been referred to.
|