Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add SLIM Baseline decision table to make tests easier to read #965
The aim of the baseline decision table is to make tests easier to read.
This makes your table more readable. It is also easier to maintain in case a value must be changed.
Given I have at least one milk remaining
|baseline: should I buy milk |
for more details see: FitNesse.SuiteAcceptanceTests.SuiteSlimTests.BaseLineDecisionTable
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.
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 :-)
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.