Category: Annoyances (Page 2 of 3)

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.

Our project has had enough time lately to really focus on some good clean up around the codebase. The project has been under major development for well over a year with plenty of people having worked on it so I find it an interesting experience to see from a high level how things are. FxCop helps us to a certain degree but here’s some very simple metrics I’ve been using to help draw out things to fix:

• ToDo‘s indicating unfinished tasks or notes made by other people. Each represents a signpost that forces people to pause or question what’s there. Each should be considered individually and should be completed, or deleted where possible. Resharper makes it even easier to find them with their TODO Explorer. Our project had a total of five of them.
• Ignored tests are large potential sources of problems, indicating that code could be untested, or a test is not providing the feedback that it should be. There tests should be rewritten, implemented or deleted if they are no longer needed so people don’t need to maintain them. Our project’s grand total… 12 out of 2390.
• Commented code is an obvious code smell, often created by many different reasons (the trick, like the above items are to find out why they’re there). Sometimes the code surrounding the comment may not be readable enough for someone to follow through and that’s easy to fix by applying a variety of refactoring techniques. Other times, commented code may be out of date and is left there because someone wanted to show how something is different – I would use refactoring such as extract method or variable, rename method or variable to help give additional context to get rid of the old code as it’s more important for people to understand what is working now more so than what it is. As a last resort, comments may be there to help explain to other developers why something is there and may be a pragmatic solution to an otherwise convoluted context. These should be exceptional and I would be greatly concerned if these were everywhere. My metric for this was very high, at 6730 lines out of 173122 lines of code although I think most of them are the .Net designer generated code for Winforms and ASP.Net pages.

Overall I was surprised at how little there was to fix with these considering how quickly the codebase has been moving and how many developers have been involved. It’s great to see everyone living the values and I think it shows in the quality of the software.