It always amazes me at how many people misinterpret FIT (Framework for Integrated Testing) and I guess it’s based on the way that it’s been marketed. I’m not exactly a big fan of FIT and the biggest reason is that people don’t really understand what it’s best for, and use it all over the place where it’s not very appropriate more so than people who do know what they’re doing with it. In the last month, I’d heard statements such as “FIT is good for driving tests below the UI layer”, “FIT is great for acceptance tests”, or “We use FIT all the time”. Please stop this!
Let’s have a look at this table I put together that compares FIT and JUnit. Of course, this comparison also applies when comparing FIT to NUnit or one of its other close brethren (TestNG, etc):
Let’s get this straight: The only thing FIT is good for, is using it as a tool to help communicate with a customer. That’s it. It’s terrible for writing automated test suites, FIT encourages terrible programming habits, IDEs offer very minimal tool support and many developers don’t seem to really understand, nor want to understand how it works. I’ve seen a test suite where developers deployed FIT tests to a web container because “it was HTML” and they thought it had to be deployed for it to run. Grrrr.
The biggest barrier for FIT is that it requires a lot of education around how developers best use it, how they use it to help aid communication, and then understanding how to maintain it. Unfortunately I’ve never seen the payback you get from investing this time that’s better spent directly trying to improve the communication gap. I think it’s because the conventions used to bridge HTML to code aren’t natural and, without spending the effort to really help developers understand it, quickly leading to a whole mess of tightly coupled code and eventually, test coma.
The recommendation
I’d use FIT sporadically to help bridge gaps between the team (analysts, developers, testers) and the customer – especially for data driven examples. Acceptance level tests in JUnit should be refactored to a point where it’s understandable to customers (i.e. using as much of their language as possible). If you decide to go down the FIT route, refactor mercilessly to split out what the FIT fixture do and how they do that (some sort of driver, component, etc). In my experience, the latter should be immediately usable in another test framework, and in fact, should be what you’re striving to reuse in that other test framework.
