John Luif

I’m a big fan of FIT or maybe I should say FITnesse.  I have used it for several projects but I have currently reached a road block.  My current usage for FIT is mocking messages that will be sent by other systems.  So let me step back and explain the architecture.  A message bus is being built along with a central data repository that has a web service sitting on top of it.  So data from many disconnected system is being sent through the message bus then stored in a central repository via a web service to get a better view of data across the enterprise.

The testing challenge is mocking messages coming from these disconnected systems into the message hub, through the web service and into the database in an easy to use interface that the end user can leverage.  FIT works great for small input messages and small-large output messages.  This is the case for a simple retrieve or search operation.  The difficulty comes in when an input message has 700+ elements.  I’m building messages using input data from tables in FITnesse then sending them into the message bus.  As you could imagine 700+ elements is a big table and totally defeats the purpose of FIT which is to allow the end user to write system level tests.  This particular input message is calling a ‘save’ operation but the kicker is this is a one way operation so there is no response message to compare against and there is not a retrieve operation for what was just saved.  This may seem illogical but the information being saved is for aggregated view purposes using reports.  Where it is being saved is not the system of record so the sending system does not care what happens on the other end.  So to check if the massage saved correctly one has to go to the database and retrieve the information.  The input message is shredded into several tables so the SQL can get quite large.

As you can probably tell from the above I’m punting on FITnesse for this testing effort.  As much as I wanted the end user to be able to construct a message easily using FITnesse this particular case just does not work well with FITnesse.

The alternative is using pre-built message files that can be feed into the system, then interrogate the database for the expected values.  This will still be automated to a large extent but will not be as flexible as FITnesse.  I’m sure this idea will evolve over time and will lead to something pretty useful.