The FitLibrary has been recently ported to .Net, and I love using the DoFixture. One problem is that the normal DoRow and DoCell methods of the Fixture class don’t run in the DoFixture. With other fixtures, I’m used to hooking into to these places in order to spread logic throughout my FIT test. DoFixture uses two new methods:
System.Collections.IEnumerable ParameterCells(CellRange theCells)
System.Collections.IEnumerable MethodCells(CellRange theCells)
This is how the DoFixture implements it’s special behavior. For example:
|Make Sure File|taxes.txt|Was Saved|
This is a simple fixture that makes sure the system saves a file “taxes.txt”. Here, I’m not using the built-in Check method. I’m implementing one myself. Either the file was saved or it wasn’t.
My underlying fixture will look like this:
This works, but will throw an exception instead of failing the test. I need to register a FIT failure and not an exception. FIT treats these two differently. In order to fail a FIT test, I have to use the Wrong(Parse theParse) method. I have to have the current Parse object in order to call this method. The Parse object is the current cell/row/table. The FIT table is composed of a Parse hierarchy. I don’t really like the way it’s set up, but that’s not the point of this post.
In order to call the Wrong(…) method to fail the test correctly with a reason to output to the screen, I must obtain the current Parse object. Because the DoFixture doesn’t fire the virtual DoCell or DoRow method, I can’t use these. Instead, I’ll override a DoFixture method that fires for every row and modify my fixture like this:
With this code, I have my fixture maintain the current Parse (I’m tracking the current row) so that when a line fails, I can properly fail the test with an appropriate message. This is a much better solution that throwing an exception. Throwing an exception means that the test environment blew up and needs to be fixed. Test failures mean the code broke. An exceptioin means the FitNesse server broke..