---

A Scenario table is a table that can be called from other tables; namely ScriptTable and DecisionTable.

The format of a Scenario table is the same as the format of a ScriptTable, but with a few differences. You can see a Scenario table in action here.

The basic format looks like this:

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

The first word in the table is Scenario. Following that is the signature of the scenario. This signature is a lot like a function declaration. The name of the scenario in the table above is WidgetRenders, and it takes two arguments: wikiText and htmlText. Notice how this looks a lot like a function call in a ScriptTable. The name is composed of every other table cell appropriately camel-cased. The arguments are the intervening cells, also appropriately camel-cased. Scenario names will be camel-cased with a leading upper-case letter. Arguments will be camel-cased with a leading lower-case letter.

The body of the scenario uses the arguments by prefixing them with an '@' sign. The token that follows the '@' must be the camel-cased name of the argument.

Here is the way this scenario is called from a DecisionTable

widget renders
wiki text	html text
this is ''italic'' text	this is <i>italic</i> text	italic widget
this is '''bold''' text	this is <b>bold</b> text	bold widget

Notice that the name of the decision table, once camel-cased, will be WidgetRenders. Since this is the name of the above scenario, the scenario will be called rather than a fixture. This is important! Remember that if a scenario is on your page, or included into your page, then its name will override any fixture that has the same name. Scenarios come first!

If you'd rather you can reference the scenario with parameters so long as you make sure the argument names in the reference exactly match the argument names in the declaration. For example the above test could have been written as:

widget	wiki text	renders	html text
wiki text	html text
this is ''italic'' text	this is <i>italic</i> text	italic widget
this is '''bold''' text	this is <b>bold</b> text	bold widget

The column headers of the DecisionTable are named for the arguments of the scenario (again, once properly camel-cased). The scenario processor simply replaces the arguments in the scenario with the contents of the table cells below the corresponding header.

Notice that there is no concept of an output header; i.e. there is no '?' in any of the column headers. A DecisionTable that calls a ScenarioTable does not make any assertions of its own. Rather it relies on the Scenario table to do the asserting. If you look at the ScenarioTable above, it uses the check keyword to make the assertion. Again, this is important. When you call a Scenario, you only pass data into it. You don't get data back out of it. Scenarios have no return value.

If you hit the test button, you will see the scenario operate. It's pretty self-explanatory. If you look at the resulting DecisionTable you'll see that an extra column has been added to each row. That column contains a collapsed section with the entire scenario table with all the arguments replaced. You can expand it by clicking on the litte arrow. Try it.

You can also call a scenario from a script table. Take a look at this:

Script
widget	!3 hello	renders	<h3>hello</h3>

Notice how the scenario is called exactly the way a function is called. Remember though that scenarios do not have return values. So you can't call a scenario from within a 'check' or 'show' row in a script table. Also keep in mind that scenario names come first, so a scenario will override a function in the current fixture.

By the way, what fixture was being used here? If you look inside the No Peeking section above, you'll see where I started the fixture. What's neat about this is that you can start any fixture you like, so long as it has appropriately named functions. So the scenario and script calls are polymorphic with respect to the fixture. (Let the reader understand and beware!)

Scenarios can also be nested! If you hit the test button, you'll see scenarios executing within other scenarios.

scenario	make page	page name	with	wikiText
create page	@pageName	with content	@wikiText
check	request page	@pageName	200

scenario	page	wiki text	renders	html text
make page	MyPage	with	@wikiText
ensure	content matches	@htmlText
show	content

Script
page	!3 hello	renders	<h3>hello</h3>

I'll leave you with one last thought. There are no if or while statements within scenarios. They are macros, not programs. They are constructed via text substitution. Their purpose is to help you eliminate redundancy in your tests.

Scenario Libraries

See <UserGuide.SpecialPages. You can place libraries of scenarios into pages named ScenarioLibrary. These pages will be automatically included into any Slim test page using the familiar uncle hierarchy used for SetUp, TearDown, etc. ScenarioLibrary pages are special because all uncles and brothers are loaded.