CODEWITHSUNDEEP
testingfitnesse
Subu
Subu

Reputation: 33

Fitnesse - can we split a large table which depends on a lot of values but has no intermediate result?

I've just started working with fitnesse over the past month or so.

I have about 50-60 different inputs which will drive a result. So far, I have been unable to find any intermediate results that I can capture and set aside.

Taking the example of a discount calculation, there are a number of values which need to be captured over a three or four page wizard. These will then be used to calculate the discount. However, there is a single service that takes all the inputs and calculates the discount. The components of the discount calculation also need to be illustrated.

As a specific example, let's say the user can select any or all of options A, B, C, in a UI, and each option has certain values associated, which the user enters in a wizard, which go into the calculation of a discount. All the options may not be associated with all the properties. My fitnesse table is required to look like:

             Property A     Property B        Property C   Expected value
   Option A        5                6                n/a          5
   Option B       n/a              n/a               10          2
   Option C       10               n/a               10          3

(n/a indicates that the property is not applicable to that option)

The problem here is that I have a single service to be called, which can't be changed, which will take the entire set of options and properties selected, and return a total discount, as well as individual discount components per option selected. The users expect the individual components to also be tested on the fitnesse page.

For a small set of properties and options, this shouldn't be too much of a problem, but I'm looking at likely around 15 or more options, and, in total, more than 50 properties, not all of which are applicable to each of the options.

Is there any way I can split this into multiple tables? Could anyone please offer any suggestions on how I can approach this ? I'm worried about both performance and readibility of the test here. I've not yet started on it, but I was trying to see if there were any alternative approaches, before starting out, since I'm not really familiar with all the possible options that may be available to me here, and going with one humongous table didn't sound good.

Thanks in advance !!

thanks, Subu

Upvotes: 2

Views: 517

Answers (1)

Subu
Subu

Reputation: 33

One option which I have been working on is to define sub tables of my own :

Main Table

 SubTable:com.test.Table1
                   Property1         Property2   
      Option A      5                    6
      Option D      10                   7

 SubTable:com.test.Table2
                    Property3         Property4
      Option B       12                n/a
      Option C       15                 10

The MainTable is the actual fitnesse table. "SubTable" is just a string that I use as a delimiter between my sub tables, to find the start of a new sub table. Following "SubTable", I can go the generic route and define the class that needs to be instantiated to handle this.

For the sake of keeping as generic, and as close to the usual fitnesse as possible, the sub table classes should also behave exactly the same way that a normal fitnesse table does, with a doTable() method.

It is upto the logic in MainTable.java to parse the individual rows, group them into sub tables, instantiate the individual handling classes with reflection, and pass the rows into the doTable() invocation. The sub table will then perform logic and validation of its own, and then return pass/fail rows. MainTable.java would then collate all the results returned by all the sub tables and display them.

This seems to work for me, so far. The column spread does decrease a lot, provided the sub table rows are grouped properly.

Please anyone let me know if you can think of a better way out than this.

Upvotes: 1

Related Questions