Why Limit Fit?

There is a common notion that FIT is for customer tests and xUnit is for programmer tests. I've certainly lived by this thinking. I've even blogged about acceptable duplication between customer and programmer tests. But I've been struggling with it lately. In many FIT tables, especially the ones that describe business rules based on conditions:

validation rules
a	b	c	valid?
yes	yes	yes	yes
yes	yes	no	yes
yes	no	yes	no
etc	etc	etc	etc

I've noticed that these tables lead me and my team to classes that operate directly on the basis of the described conditions. In this case, the table itself *could* double as a unit test. In fact, the unit tests end up looking very much like a different (less expressive) expression of the same thing:

[Test] public void ShouldBeValidIfAandBandC()
{
  classUnderTest.a(true);
  classUnderTest.b(true);
  classUnderTest.c(true);
  Assert.IsTrue(classUnderTest.IsValid());
}

Maybe that's expressive enough, but there are one of these test methods for every row in the table above, which is much more compact and therefore easier to understand, in my view.

The school of thought that says FIT is for customers and xUnit is for programmers leads us to keep both of these tests around. But why do we need that one thing expressed in two places, or in two languages? DRY, right?

There are arguments (that I'll confess that I've made with some passion) that FIT tables don't compile with the code, the don't *belong* to developers, etc. There are two problems I have w/ this thinking (and I have to reiterate here that it's MY thinking I'm criticizing - if yours is in alignment that's pure coincidence :) ) - one is that we're assigning a tool to a class of people (or roles) and thereby limiting its potential usefulness as is - two is that we're subconsciously limiting the directions in which FIT might grow. If we *think* FIT is for one thing, then it will be so.

What if, for example, we had an xUnit extension that would execute specific FIT pages as part of our unit test run? If we kept these with our source code (and in source control), then we have a great new way to express our unit tests. The big missing piece here becomes the compile step in the TDD cycle - and I don't see that getting resolved very easily. But things that IntelliJ[?] and TestDriven.[?]NET allow you to do, like clicking on a failed test and jumping to the point of failure - that becomes a matter of tools. And who knows what these tools might look like if we accept tabular expression of tests as a normal way to do unit testing.

The other thing that's been weighing on me is that I see a lot of functional/integration testing showing up in the xUnit test suites. I think this may be OK in some cases, but in others I think it's a problem. A perfect example would be the unit tests for FitNesse.NET - many of which I wrote myself. There are *unit* tests that describe entire tables in html in text strings and then verify that the counts are right after processing. Unit tests? I think not. Plus, they are much more difficult to read than the rendered HTML. So why express them this way when we can just use FixtureFixture[?]? In fact, I've been planning to re-express them using FixtureFixture[?]. If I do this, do I keep the NUnit tests?

If I get rid of them, then some of the artifacts of TDD are gone. So I guess to really do that justice I'd have to rewrite everything starting w/ FixtureFixture[?]. But then again, we refactor our xUnit tests as a matter of course in order to make them more expressive. Why not refactor them across the execution environment barrier?

---

!commentForm