Extend all arg table by adding information about current row number a…

[pwszpl]

…nd total row numbers that are definied in base decision table.

[fhoeben]

I believe having only one variable with each value would be better, more clear.

And maybe the names can more intuitive also? Instead of SCENARIO_TABLE_, maybe INVOKING_DECISION_TABLE_.

To me it seems like a bad practice to make the fixture depend on the number of rows in the invoking decision table, or its current row. Why do you need that?
The current row seems like something a fixture could easily track itself, have the scenario invoke a specific method at the first/last row.

[fhoeben]

Why do you put both values in the arguments twice (under different names)?

[pwszpl]

I wanted a short name and long name in case someone might be using CURRENT_ROW in their decision table as actual input argument. Now I can see that I would overwrite them anyway so there is no point to this. I will leave one variable for each value here.

[fhoeben]

The word 'fundamental' does not seem quite appropriate here, in http://fitnesse.org/FitNesse.UserGuide.WritingAcceptanceTests.SliM.ScenarioTable 'invoking' is used. Would that be suitable here?

And instead of 'keeps' I recommend 'contains'.

[pwszpl]

That's a good suggestion. I will change that in next commit :)

[pwszpl]

I believe having only one variable with each value would be better, more clear.

As I said in the comment, my intention was to create secondary name in case, someone might be already using this name in their tests. But after consideration you are right to leave only one value.

And maybe the names can more intuitive also? Instead of SCENARIO_TABLE_, maybe INVOKING_DECISION_TABLE_.

INVOKING_DECISION_TABLE_ seems a little too long, but I like sound of it. How about making acrynonym of it. Something like IDT_TOTAL_ROWS and IDT_CURRENT_ROW?

To me it seems like a bad practice to make the fixture depend on the number of rows in the invoking decision table, or its current row. Why do you need that? The current row seems like something a fixture could easily track itself, have the scenario invoke a specific method at the first/last row.

In my case I need to keep track of current row number so I can store some data from test (like execution logs) under unique identificatior. Yeah, I could do it by adding a column with row number to every decision table, but that is hard to maintain (and seems like an overkill, espacially if I can have it automatically with two lines of code ). Number of total rows is not something I use as of now. I added it just in case someone might need it.

[fhoeben]

Why did you add this line?

[fhoeben]

In my case I need to keep track of current row number so I can store some data from test (like execution logs) under unique identificatior. Yeah, I could do it by adding a column with row number to every decision table, but that is hard to maintain (and seems like an overkill, espacially if I can have it automatically with two lines of code ). Number of total rows is not something I use as of now. I added it just in case someone might need it.

I was not thinking of having a row number in the wiki itself, but just keeping a variable in the fixture class that you increment for each row (either by an explicit row/call in the scenario or as a side effect of one of the other methods of your fixture). The advantage of that is that the logic is truly in the fixture and decoupled from the wiki and you can choose whether the counter should be reset for for each decision table or whether a global counter should be maintained for an entire page/suite (which has multiple decision tables using the same fixture).

You could even add a method that you call from a 'show row' (at the end of the scenario), or that you fill as an output variable so it can be shown in the decision table, that shows a hyperlink to the logs specifically of that execution/decision table row (and then increments the counter). All that is possible without changing the Slim table...

In my fixture project I keep a field nextSequenceNr in the Environment class specifically to have a global counter over an entire suite for fixtures that want something like that.

[pwszpl]

Implementing it inside fixture is just cumbersome. For example, your implementation helps with keeping id unique, but it doesn't provide constitency throught many runs over the same suite. It could be done better, but still it might be a solution if you have couple of fixtures to deal with. It's worse if you have few dozens, some of which are yours, but most are from external plugins over which you don't have control over, and you would need to provide your own implelentation for it.

I get your point that you want to keep test logic outside of FitNesse implementation and every user might have a different needs, so it might not be usable by everyone. But if there is a way for FitNesse to easily provide something that might be needed, and saves you hundreds lines of implemntation, then why shouldn't it? As this scenario table is not yet released it just feels like a good time to add this. There is no problem with backward compatibilty and anyone that might use this scenario table will just need to keep in mind that this feature exists.

@fhoeben what do you think about this?