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

Add SLIM Baseline decision table to make tests easier to read #965

Merged
merged 1 commit into from Oct 30, 2016

Conversation

Projects
None yet
3 participants
@six42
Contributor

six42 commented Aug 25, 2016

The aim of the baseline decision table is to make tests easier to read.

Background
The idea of a decision table is to demonstrate how different combinations of input parameters generate different results.
To make the impact of each parameter to the output results transparent it is good practice to modify just one parameter from row to row.
For big tables with many input parameters it is often not immediately visible to the reader which parameter changes from row to row.

Syntax
As a user of the baseline decision table you specify in the first row below the header in each column the values for all input and output parameters.
This defines your base scenario and so far this is 100% identical to a normal decision table.
In all following lines you just specify the values which differ from the base scenario all other columns are left empty.

This makes your table more readable. It is also easier to maintain in case a value must be changed.
Don't repeat yourself is a good rule even when you write test cases. :)

Fixture Code
When the baseline decision table is tested all empty columns are filled by the Slim test system with the corresponding values from the base scenario.
In all other aspects the bahviour is identical to the decision table.
Your fixture code is identical to a decision table. The fixture will not be able to identif any difference between a baseline decision table and a normal decision table.

Example
Let's look at an example which you know already from the Decision Table

Given I have at least one milk remaining
Then I should NOT go to the store

|baseline: should I buy milk |

cash in wallet credit card pints of milk remaining go to store?
0 no 1 no
2
7
10
yes
10 yes
1 1

for more details see: FitNesse.SuiteAcceptanceTests.SuiteSlimTests.BaseLineDecisionTable

@six42 six42 changed the title from Add SLIM Baseline decision table to make tests easierr to read to Add SLIM Baseline decision table to make tests easier to read Aug 25, 2016

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Aug 25, 2016

Collaborator

Can't you just do this with a normal decision table where you do a null/empty string check on the input? Instead of using primitives you can use their object counterparts.

Collaborator

amolenaar commented Aug 25, 2016

Can't you just do this with a normal decision table where you do a null/empty string check on the input? Instead of using primitives you can use their object counterparts.

@six42

This comment has been minimized.

Show comment
Hide comment
@six42

six42 Aug 25, 2016

Contributor

A fixture could implement an identical behaviour for inputs. But not for outputs, except the implementor switches to a Slim TableTable type and you do everything in your fixture code.

But the goal is to decouple fixture implementation and test case format. The implementation stays as easy as with a normal decision table. And the test case writer gets two ways to express his requirements and can choose whatever he thinks is best suited in the current situation.

Contributor

six42 commented Aug 25, 2016

A fixture could implement an identical behaviour for inputs. But not for outputs, except the implementor switches to a Slim TableTable type and you do everything in your fixture code.

But the goal is to decouple fixture implementation and test case format. The implementation stays as easy as with a normal decision table. And the test case writer gets two ways to express his requirements and can choose whatever he thinks is best suited in the current situation.

Added Baseline Decision Table
See FitNesse.SuiteAcceptanceTests.SuiteSlimTests.BaseLineDecisionTable for details
@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Oct 19, 2016

Collaborator

One question: the changes are relative to the top row (the base scenario), right?

Collaborator

amolenaar commented Oct 19, 2016

One question: the changes are relative to the top row (the base scenario), right?

@fhoeben

This comment has been minimized.

Show comment
Hide comment
@fhoeben

fhoeben Oct 19, 2016

Contributor

I've never had a need for such a decision table, but there are more table types I've never used. One question though: how hard would it be to just make the standard codebase extensible enough so that this table type can be delivered by a plugin? Maybe that will create some extra flexibility (other) plugin developers may also benefit from, and you don't have to convince @amolenaar that this is a great extra table type :-)

Contributor

fhoeben commented Oct 19, 2016

I've never had a need for such a decision table, but there are more table types I've never used. One question though: how hard would it be to just make the standard codebase extensible enough so that this table type can be delivered by a plugin? Maybe that will create some extra flexibility (other) plugin developers may also benefit from, and you don't have to convince @amolenaar that this is a great extra table type :-)

@six42

This comment has been minimized.

Show comment
Hide comment
@six42

six42 Oct 19, 2016

Contributor

Yes

Contributor

six42 commented Oct 19, 2016

Yes

@six42

This comment has been minimized.

Show comment
Hide comment
@six42

six42 Oct 19, 2016

Contributor

A different design option would be to make it relative to the previous row.
But i think this becomes to difficult to keep the overview.
In the 10th row you have to trace back all previous 9 rows to understand which values are used.

Contributor

six42 commented Oct 19, 2016

A different design option would be to make it relative to the previous row.
But i think this becomes to difficult to keep the overview.
In the 10th row you have to trace back all previous 9 rows to understand which values are used.

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Oct 20, 2016

Collaborator

I just gave it a swing. It does read in a clean way. To me it's more obvious to relate the alterations to the top row.

I think it would be nice if the blank fields were filled in after a test execution, so it's really clear which values were tested with. Just like blank fields are filled with output in a normal decision table (tagged as "ignored", so they appear on a blue background).

Found one issue in the code. The second parameter of DecisionTableCaller is a boolean. This usually denotes there are actually 2 different things going on, so they should be separated in a different way (composition, subclassing, whatever). I thing the baseline table should use its own DecisionTableCaller implementation. This would also add to extensibility of this table type.

Collaborator

amolenaar commented Oct 20, 2016

I just gave it a swing. It does read in a clean way. To me it's more obvious to relate the alterations to the top row.

I think it would be nice if the blank fields were filled in after a test execution, so it's really clear which values were tested with. Just like blank fields are filled with output in a normal decision table (tagged as "ignored", so they appear on a blue background).

Found one issue in the code. The second parameter of DecisionTableCaller is a boolean. This usually denotes there are actually 2 different things going on, so they should be separated in a different way (composition, subclassing, whatever). I thing the baseline table should use its own DecisionTableCaller implementation. This would also add to extensibility of this table type.

@amolenaar amolenaar merged commit 6a228eb into unclebob:master Oct 30, 2016

amolenaar added a commit that referenced this pull request Oct 30, 2016

Merge pull request #965 from six42/baselinetable
Add SLIM Baseline decision table to make tests easier to read

@six42 six42 deleted the six42:baselinetable branch Nov 3, 2016

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