114 lines
5.6 KiB
Plaintext
114 lines
5.6 KiB
Plaintext
The Hybrid Decision Table is a combination of the Decision Table and the Dynamic Decision Table.
|
|
A decision table requires for each table column the definition of a method.
|
|
This is impractical when you deal with structured data that has a varying size like: hash maps, XML, properties, database tables, etc.
|
|
The number of methods you need to write could be infinite.
|
|
|
|
A dynamic decision table has just one method which is called for all columns and your fixture has to do the dispatching.
|
|
This solves the above problem but dispatching should be done by the test system and not by your fixture.
|
|
|
|
Sometimes you want both features in one table and that is when you use the Hybrid Decision table.
|
|
|
|
The Hybrid Decision Table allows the methods called for each column to be
|
|
redefined and method parameters can be extracted from the column names.
|
|
|
|
|
|
|
|
Example
|
|
|
|
!*> Setup
|
|
|
|
|import |
|
|
|fitnesse.slim.test|
|
|
|java.util |
|
|
|
|
!5 define some string variables (just to show that this is supported)
|
|
|script: Test Query|5 |
|
|
|$S1= |echo|abcdefghijklmnopqrstuvwxyz |
|
|
|$S2= |echo|123456789 |
|
|
|$S3= |echo|"The fox jumps over the wall."|
|
|
|
|
!define SLIM_DT_GETTER (!-
|
|
{
|
|
"FormatVersion":"1.0",
|
|
"MethodExtractorRules":[
|
|
{
|
|
"Scope":"property\\s+(\\w*)\\s*",
|
|
"TargetName":"get property",
|
|
"Parameters":"$1"
|
|
},
|
|
{
|
|
"Scope":"has Value\\s+'(\\w*)'\\s*",
|
|
"TargetName":"contains Value",
|
|
"Parameters":"$1"
|
|
}
|
|
]
|
|
}
|
|
-!)
|
|
!define SLIM_DT_SETTER (!-
|
|
{
|
|
"FormatVersion":"1.0",
|
|
"MethodExtractorRules":[
|
|
{
|
|
"Scope":"property\\s+(\\w*)\\s*",
|
|
"TargetName":"set property",
|
|
"Parameters":"$1"
|
|
},
|
|
{
|
|
"Scope":".+",
|
|
"TargetName":"$0",
|
|
"Parameters":""
|
|
}
|
|
]
|
|
}
|
|
-!)
|
|
|
|
*!
|
|
|
|
!3 Based on your test cases you might expect or need to add a varying number of properties to a collection.
|
|
!4 Test Case with 2 properties
|
|
|Properties |
|
|
|#|property a|property b |size?|key set?|property a?|property b?|to string? |has Value '123456789' ?|
|
|
| |$S1 |123456789 |2 |[b, a] |$S1 |123456789 |{b=123456789, a=abcdefghijklmnopqrstuvwxyz} |true |
|
|
| |$S2 |"The fox jumps over the wall."|2 |[b, a] |123456789 |$S3 |{b="The fox jumps over the wall.", a=123456789} |true |
|
|
| |$S3 |abcdefghijklmnopqrstuvwxyz |2 |[b, a] |$S3 |$S1 |{b=abcdefghijklmnopqrstuvwxyz, a="The fox jumps over the wall."}|false |
|
|
|
|
!4 Test Case with 3 properties added and 2 expected
|
|
|Properties |
|
|
|#|property NEW|property a|property b|size?|key set?|property NEW?|property b?|to string? |has Value '123456789' ?|has Value '!-FitNesse-!'?|
|
|
| |Hello |$S1 |$S2 |3 | |Hello |123456789 | |true |false |
|
|
| |!-FitNesse-!|$S2 |$S3 |3 | | |$S3 | |true |true |
|
|
| |World |$S3 |$S1 |3 | |World |$S1 |{b=abcdefghijklmnopqrstuvwxyz, a="The fox jumps over the wall.", NEW=World}|false |false |
|
|
|
|
|
|
!4 Look in the collapsed setup how the mapping between column names and method names is done.
|
|
The magic is done with two variables:
|
|
SLIM_DT_SETTER - for input columns
|
|
SLIM_DT_GETTER - for output columns
|
|
|
|
For each variable you can define a list of ''Method Extractor Rules'' in JSON format. A Method Extractor Rule has 3 properties:
|
|
1. Scope - a regular expression which identifies all columns for which this extractor should be applied.
|
|
2. Target Name - a replacement string for the "Column Name" regular expression. This will be passed to the Disgracer to generate the final method name.
|
|
3. Parameters - a colon separated list of parameters passed to the method called.
|
|
|
|
The list of rules is preceded with a version number ''Format Version''. This must currently be always "1.0".
|
|
Future versions might define additional features and will require a different version number.
|
|
|
|
If no Method Extractor Rule matches the current column name than the default rules of the Decision Table are used ("set " + column name).
|
|
|
|
The Hybrid Decision Table is no new table type but it modifies the behavior of the decision table with the help of the above variables.
|
|
This has the advantage that you don't need to specify the table type in your test cases
|
|
and leaves the decision to the implementer of the test cases if he wants to use a hybrid, dynamic or normal decision table.
|
|
|
|
|
|
!4 IMPORTANT: to avoid side effects always add a >TearDown page to reset the mappings to the defaults.
|
|
|
|
|
|
!2 Warning: The Hybrid Decision Table is still experimental
|
|
The way how the method names are configured (via variables) might change.
|
|
Be prepared to refactor your tests if you use this feature.
|
|
Your ideas for a final solution are welcome please give feedback on the [[!-FitNesse-! mail group][https://groups.yahoo.com/neo/groups/fitnesse/info]]
|
|
|
|
|
|
|
|
Further Reading:
|
|
!contents -R2 -g -p -f -h |