Quick Note: I love *what* Fit testing accomplishes, but the mechanics are an issue. There’s a rumor floating around that a bunch of test automation gurus are going to work up some ideas for how to “save” Fit testing. Anybody feel like commenting? I don’t know anymore details that that.
I’ve had doubts for months, but I think I finally soured on Fit testing within about 5 minutes last week. Here’s why:
- To fix an existing test I caught myself using 2-3 different low level tricks within Fit. I built a couple different custom type handler and injected them, overrode a DoTables() method, and some other bit of hackery that involved low level knowledge of Fit internals. I found myself using 4-5 different Fixture classes in a single class. It suddenly occurred to me that there was no way in hell that I was going to be able to completely transition this stuff to the client’s testers and developers before I leave (especially since I work beside them instead of working with them, but that’s a different battle). It just requires too much internal knowledge of Fit mechanics to do anything outside of basic set-based testing.
- Nat Pryce aptly described the Fit engine mechanics as “reflectopornographic“, and I don’t want to use something described as “reflectopornographic.” If you’ve worked with Fit testing before, you’re probably laughing along with that right now.
- Some things are easier in Fit tests than xUnit tests, but for larger flow based tests I’d rather just write code alone. If I had it to do over again, I’d keep Fit (StoryTeller in reality) for set-based things, but would have written a, wait for it, fluent interface test harness for the flow based testing I do against the user interface. I don’t have any participation from the customer and little from the tester, so why not use the tools I’m most comfortable with? I’m spending too much time hunting down test grammars from the Fixture classes to remember what to type into the Fit editing window. Intellisense anyone?
When I say set-based here, I’m talking about tests that can very accurately be expressed completely in 2 dimensional tables. X number of inputs leading to Y number of outputs. Fit excels at that with the ColumnFixture and RowFixture tests.
What about StoryTeller?
I’ve just done a reset on the StoryTeller UI and I’m committed to finishing it. StoryTeller is aimed very squarely as a FitNesse killer for better management and editing of Fit style tests, not as a replacement of the actual FitnesseDotNet engine. I think in the longer term I’m keeping StoryTeller for the things it is good at, but start moving more towards the xBehave tools for the flow style testing that I use DoFixture’s for today.
Regardless of whether or not you’re using Fit happily, with reservations, or just want to think about starting, I’m putting up a lessons learned post in the next couple days on Fit testing in specific and automated acceptance tests in general.