Included page: .FitNesse.SuiteAcceptanceTests.ScenarioLibrary (edit)

scenario given page page with content content
create page @page with content @content
$IT= echo @page

scenario given page page
given page @page with content nothing
$CONTENT= echo

scenario given test page page
given page @page
make @page a test page

scenario given slim test page page
given page @page with content !define TEST_SYSTEM {slim}
make @page a test page

scenario page source should have link to target
check request page @source 200
ensure content contains <a href="@target"
$IT= echo @source

scenario it should have link to target
page $IT should have link to @target

scenario and it should have link to target
page $IT should have link to @target

scenario page source should have creating link to target
check request page @source 200
ensure content contains @target<a title="create page" href="@target?edit&nonExistent=true">[?]</a>

scenario it should have creating link to target
page $IT should have creating link to @target

scenario page source should contain text
check request page @source 200
ensure content contains @text
show content

scenario page source should not contain text
check request page @source 200
reject content contains @text
show content

scenario page source should match text
check request page @source 200
ensure content matches @text
show content

scenario it should contain text
page $IT should contain @text

scenario it should not contain text
page $IT should not contain @text

scenario it should contain text in line symbol
check request page $IT 200
$@symbol= line number containing @text

scenario it should match text
page $IT should match @text

scenario test results for page source should contain text
check request page @source?test 200
ensure content contains @text
show content

scenario test results for page in debug mode source should contain text
check request page @source?test&debug 200
ensure content contains @text
show content

scenario test results for suite source should contain text
check request page @source?suite 200
ensure content contains @text
show content

scenario its test results should contain text
test results for page $IT should contain @text

scenario test ressults for page source should not contain text
check request page @source?test 200
reject content contains @text
show content

scenario and should contain text
ensure content contains @text
show content

scenario and should match text
ensure content matches @text
show content

scenario and should not contain text
reject content contains @text
show content

scenario widget wikiText should render htmlText
create page WidgetPage with content @wikiText
check request page WidgetPage 200
ensure content matches @htmlText
show content

scenario the line after should come after before
check echo int $@before < $@after

scenario pass
check echo pass pass

scenario show collapsed content
show @content

scenario show Symbol result

scenario then pass assertions pass, fail fail, ignore are ignored exception exceptions thrown
ensure content matches Assertions:<[^<]*@pass right, @fail wrong, @ignore ignored, @exception exceptions
show extract match; Assertions:<[^<]*exceptions contents 0

scenario and cell text has result result
ensure content matches class="@result">@text<
show extract match; class="[^"]+">@text< contents 0

variable defined: TestSTART=@@@START: Test specific content
variable defined: TestEND=@@@END: Test specific content

scenario and TestSystem setup is content
$CONTENT= echo $CONTENT @content

scenario and setup content is content
$CONTENT= echo $CONTENT @content

scenario and test content is content
given page $IT with content $CONTENT @@@START: Test specific content@content@@@END: Test specific content
make $IT a test page

scenario get HTML result
start Response Examiner.
setType contents
setPattern @@@START: Test specific content[^<]*(.*>)\s*@@@END: Test specific content
setGroup 1
$HTML_Result= found

scenario get HTML input
start Response Examiner.
setType pageHtml
setPattern @@@START: Test specific content[^<]*(.*>)\s*@@@END: Test specific content
setGroup 1
$HTML_Input= found
show collapsed get value


scenario get collapsed executon log for page source
check request page @source?executionLog 200
show content

scenario when page source is tested
check request page @source?test 200
show collapsed content

scenario when page source is tested and HTML is extracted
when page @source is tested
get HTML result
get HTML input

Included page: .FitNesse.SuiteAcceptanceTests.SuiteSlimTests.HybridDecisionTable.SetUp (edit)

Import
fitnesse.fixtures


Library
echo fixture


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

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."

variable defined: 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" } ] } -!
variable defined: SLIM_DT_SETTER=!- { "FormatVersion":"1.0", "MethodExtractorRules":[ { "Scope":"property\\s+(\\w*)\\s*", "TargetName":"set property", "Parameters":"$1" }, { "Scope":".+", "TargetName":"$0", "Parameters":"" } ] } -!


Based on your test cases you might expect or need to add a varying number of properties to a collection.

Test Case with 2 properties

Properties
# property a property b size? property a? property b? has Value '123456789' ?
$S1 123456789 2 $S1 123456789 true
$S2 "The fox jumps over the wall." 2 123456789 $S3 true
$S3 abcdefghijklmnopqrstuvwxyz 2 $S3 $S1 false

Test Case with 3 properties added and 2 expected

Properties
# property NEW property a property b size? property NEW? property b? 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 false false


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.


IMPORTANT: to avoid side effects always add a >TearDown page to reset the mappings to the defaults.



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



Further Reading:
Contents:

Included page: .FitNesse.SuiteAcceptanceTests.SuiteSlimTests.HybridDecisionTable.TearDown (edit)

Reset variables to get normal behaviour back.
variable defined: SLIM_DT_GETTER=
variable defined: SLIM_DT_SETTER=