Let's Code: Test-Driven JavaScript, my new screencast series on rigorous, professional JavaScript development, is now available! Check out the demo video here.

 Print

Five Ways to Misuse Fit

08 Oct, 2007

As the Agile Alliance's Functional Testing Tool workshop draws near and the conversations heat up, I'm thinking a lot about Fit. Coincidentally, I'm also preparing for my Fit presentation at the Agile Development Practices conference in Florida. Just this evening, the following list of terrible things bubbled to the top of my brain. I give you: five ways to misuse Fit.

(This is written in the ever-popular "rant" style. It's meant to be a bit inflammatory... but it's all true.)

Misuse #1: Use Fit for Test Automation

Sure, it's called "Framework for Integrated Test". The key word there, though, is "Integrated", not "Test". Fit is actually a fairly weak test automation tool. There are dozens tools (xUnit, Watir, Selenium, not to mention all the high-priced screen scrapers) that do test automation. They do it better than Fit does.

Fit's strength--the one thing it does better than any other tool I know--is that customers are comfortable providing examples in tables. It's a great tool for communicating with customers. If you use it to automate your regression tests, you will come to regret it. If you use it to enhance your collaboration with customers, you'll be much happier.

Misuse #2: Customer? What Customer?

Closely related with Misuse #1: The Case of the Missing Customer. If you aren't talking with domain experts when you create your Fit tables, you're probably doing it wrong. If you aren't at least showing them your Fit tables and making changes based on their feedback, you're definitely doing it wrong. If you aren't using Fit for communication and collaboration, you're just writing automated tests. In HTML! With tables! (And people complain about Javascript.) Use xUnit, for cryin' out loud!

Misuse #3: Write Integration Tests

People seem to think most naturally in an imperative, flow style. "First, do this. Then, do that. Now check this. Next, do that. (etc)" It's easy to write your Fit tests in the same way. The problem is that each example ends up being many lines long. Worse, most of the examples end up being boilerplate. Next, you find yourself wishing for variables, subroutines, setup and teardown routines, and so on. Next thing you know, you've got a full-fledged, impressively crappy programming language. (In HTML. With tables! Gah!) And you know what? Your customers won't be able to understand it.

Don't do that. Focus on business rules, write fixtures that test a few business objects, use Whole Value, and develop your Ubiquitous Language through conversations with your customers. Nearly all of your needs can be met with ColumnFixture and RowFixture.

(There may be a case for flow-style tests--Brian Marick and Rick Mugridge have done some interesting things in this area, and Ward Cunningham wrote a tool for the Eclipse Foundation called "Swim" that focuses on workflow examples. However, they're definitely overused by most people.)

Misuse #4: Spin Your Propeller

Fit inspires modification. It's Ward Cunningham's creation, and there's something about his work that does so. That's great! Before you lift off the ground, though, take off your propeller beanie for a moment. The whole point of Fit is to use HTML to speak the customer's language and fixtures to translate that language to code. (Hopefully, your ubiquitous language and domain-driven design make for a very thin translation layer.) Those generic, do-everything fixtures you want to create? They're just moving the test automation burden from code to HTML. (With tables!) Or worse, they're using reflecto-magic to tie your HTML to the structure of your code. Welcome to Refactoring Hell.

Misuse #5: Specify Everything

This one's my fault. When I first started using Fit, I was excited about the possibilities of creating "executable specifications". I wrote about it online and I tried to create the Fit Specification using Fit itself.

Using Fit to create executable specifications turned out to be a really bad idea. There's a maintenance burden associated with Fit: there are fixtures to maintain and HTML documents to organize. It's not too bad as long as use fixtures as your translation layer (rather than using reflection to tie directly to code), but it's still there.

Anyway, the gap between "just enough Fit examples to improve communication" and "comprehensive automated requirements specification" isn't just huge, it's crippling. Suddenly, Fit goes from being a friendly little tool to a devastating maintenance burden. Don't do that. Use Fit for communication. Need a comprehensive regression suite? Use xUnit and test-driven development instead. You'll be happier.

In Conclusion...

  1. Fit is good for communication, weak for test automation.
  2. People mostly use Fit for test automation, less for communication.
  3. Doctor, doctor, it hurts when I do this.

Further Reading

I've written about Fit before in my series on Agile Requirements. Also relevant is my piece on using Fit to test business rules.

The conversation that inspired this post was kicked off by Jeremy Miller's discussion of why he doesn't like Fit (Part 1, Part 2.) I'm not picking on Jeremy here, though--these mistakes are universal. Jeremy's posts were just the catalyst.

Jeremy's posts led me to some more discussion of Fit on Nat Pryce's blog. I disagree with several of his points, actually, but it's worth reading. Besides, where else are you going to read about reflectoporn? (Actually, you don't want to know the answer to that.)

PS: I'm much nicer in person. No, really.