Adding More Flexibility To FIT Fixtures
There’s one fixture of all the fixtures in FIT that people find the most useful… the ColumnFixture. The simplest of all, just a simple table with columns that map to object properties and methods, with each row setting values, calling methods, and verifying results. Anyhow.. in my time I’ve faced all matter of problems with ColumnFixtures, with tons of nice little smells showing up in our fitnesse tests here and there. So today, for my Friday Personal Development time at Carfax, I decided to tackle some of the problems.
Problem: Values Bleed Through
One major annoyance is that you may have cases where you want certain cells to be blank, but for other scenarios they are populated. The problem with ColumnFixture is that if you set values under a column, then the next row has a blank, it kind of “inherits” the value. Not pleasant, and this usually leads to having an extra column at the end with the heading of something like “reset values!” and every row under it just having true, with extra code written in your fixture to manually clear each and every relevant field, then just return true.
So, I simply overrode the methods doTable, doRow, and doCell to call new methods before and after they execute. This gives us 6 new simple, yet powerful methods you can add to your custom fixture: beforeTable(), afterTable(), beforeRow(), afterRow(), beforeCell(), and afterCell(). Now, instead of having to have that extra column in my test table to reset values, I can simply add:
public void beforeRow(){
surcharge = 0.00;
}
Other interesting uses of this is cleaning up anything that may have been left lying around after row or table execution, like data populated in the database or whatnot. 
More Flexible Results With OGNL
I’ll admit.. I was influenced greatly by Green Pepper Software’s product, specifically this page that shows various examples of using OGNL with results. After downloading and toying around with OGNL, I discovered it’s not really hard to implementand went about adding the functionality to ColumnFixture.
This allows users to use fancy mathematical expressions in result cells, like check that a resullt is within a range, or an equation that shows how a result relates to it’s inputs. For example, say you have a Calculator table with columns x,y, sum, and product. Under sum, you could have “sum eq (x + y)” and under product, you could have “product == (x*y)”. See here for a quick HTML dump of a test I just ran.
In addition, you could alternatively call methods on objects that are returned by your fixture methods. It becomes very useful when you have data returned that may be padded, or may be huge and you only care about a portion of it. Rather than code custom methods on your fixture, you could just do something like this:
|Error Messages|
|user action|rights|message?|
|delete page|none|message.contains('you do not have permission')|
|uplod photo|user|message.trim() eq 'Photo Uploaded'|
Well, that’s the quick and dirty. Once I clean the code up a little and write a few more tests for possible sad path cases, it’ll be available for public consumption.
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
