Andy Pols CTO, Entrepreneur

Fit Lesson 1

Write the test so it reads like a requirement specification and not a test.

I was trying to explain a FIT test to a new colleague. It soon became clear that it had been written as a test. It didn’t convey the intent of what was required. Nor did it communicate why it did what it did. There was a lot of tacit knowledge in my explanation of what was going on. It obviously failed to communicate the requirement. It did, however, test that a particular feature of the system worked!

So, what is the purpose of a FIT test?

Brian Marick makes the distinction between Business Facing tests and Technology Facing tests.

A business-facing test is one you could describe to a business expert in terms that would (or should) interest her. If you were talking on the phone and wanted to describe what questions the test answers, you would use words drawn from the business domain: “If you withdraw more money than you have in your account, does the system automatically extend you a loan for the difference?”

A technology-facing test is one you describe with words drawn from the domain of the programmers: “Different browsers implement Javascript differently, so we test whether our product works with the most important ones.”, “Or, PersistentUser#delete should not complain if the user record doesn’t exist.”

The FIT tests should be business facing, they are a communication tool with the added benefit being executable.

FIT tests should explain the requirements so that people know what the system does. The collection of FIT tests forms an executable requirement specification. They should not really be called tests at all!

Our FIT test was clearly written from a developer’s point of view. It was technology facing. Fit is probably the wrong tool for technology facing tests. I would much rather write these in a more developer friendly tool such as Java or ruby.

comments powered by Disqus