New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure scenarios invoked from scripts use the ScriptTable class of the calling script #507

Merged
merged 3 commits into from Aug 23, 2014

Conversation

Projects
None yet
2 participants
@fhoeben
Contributor

fhoeben commented Aug 20, 2014

When a custom subclass of ScriptTable is used and a scenario is invoked from the script. Currently the ScenarioTable class will always convert its contents into assertions using the standard ScriptTable class.

To me it seems more natural/expected that the ScenarioTable would use the table-class of the calling script. This view seems to be supported by the documentation (FitNesse.UserGuide.WritingAcceptanceTests.SliM.ScenarioTable) which states: "They are macros, not programs. They are constructed via text substitution." which to me indicates the type of script table used should not change when replacing lines of script with a scenario call.

ScriptTable scriptTable = new ScriptTable(newTable, id, testContext);
protected ScriptTable createChild(ScenarioTestContext testContext, SlimTable parentTable, Table newTable) {
ScriptTable scriptTable;
if (parentTable instanceof ScriptTable && !parentTable.getClass().equals(ScriptTable.class)) {

This comment has been minimized.

@amolenaar

amolenaar Aug 20, 2014

Collaborator

Why this differency in table creation? Shouldn't ScriptTable be created the same way as it's customised sub class?

@amolenaar

amolenaar Aug 20, 2014

Collaborator

Why this differency in table creation? Shouldn't ScriptTable be created the same way as it's customised sub class?

This comment has been minimized.

@fhoeben

fhoeben Aug 20, 2014

Contributor

When a DecisionTable creates a scenario the parent table is not a script.
When a ScriptTable (not a subclass is used) I avoided reflection, so no reflection was needed at all. Maybe it's premature optimization.

@fhoeben

fhoeben Aug 20, 2014

Contributor

When a DecisionTable creates a scenario the parent table is not a script.
When a ScriptTable (not a subclass is used) I avoided reflection, so no reflection was needed at all. Maybe it's premature optimization.

@fhoeben

This comment has been minimized.

Show comment
Hide comment
@fhoeben

fhoeben Aug 21, 2014

Contributor

Last commit is not really for making the ScenarioTable create custom subclasses, but the change was so small a separate branch seems wasted effort

Contributor

fhoeben commented Aug 21, 2014

Last commit is not really for making the ScenarioTable create custom subclasses, but the change was so small a separate branch seems wasted effort

@amolenaar amolenaar added this to the Next release milestone Aug 23, 2014

@amolenaar amolenaar merged commit 5994fa6 into unclebob:master Aug 23, 2014

amolenaar added a commit that referenced this pull request Aug 23, 2014

Merge pull request #507 from fhoeben/ScenarioCreatesParentScriptClass
Ensure scenarios invoked from scripts use the ScriptTable class of the calling script

@fhoeben fhoeben deleted the fhoeben:ScenarioCreatesParentScriptClass branch Jan 25, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment