Geeks With Blogs
Chris Falter .NET Design and Best Practices

I was looking for ways to improve our development process when I stumbled across the Framework for Integrated Testing (FIT).  The rest of this post is the body of an email I recently sent to my manager.

The goal of the Customer update is to migrate all their customizations to a new framework in a reliable and quick manner.  The major risks I have been able to identify are as follows:

  1. Developers won’t be able to identify all the behaviors that need to migrate.
    • Requirements are scattered.
    • Code is not organized optimally.  Much business and workflow logic is scattered throughout the UI layer, in particular. Many customizations in domain logic are located in poor locations in the domain class hierarchy; the root domain object seems to have become a catch-all location for just about anything.
  2. Manual regression testing will become a bottleneck.  It is already a serious bottleneck for other projects.
  3. Poor code organization will be perpetuated into the new source code base.  As a result, the project will proceed more slowly (due to high bug rate and unnecessary complexity), and subsequent evolution of the code will be hampered as well.
  4. Lack of an automated testing framework will impede any efforts to refactor code.  Since this project by definition requires an extensive reworking of our source code, this risk is quite serious.

Note to readers: I'm sure many of you have faced these kinds of challenges on one or more projects.  Read on to discover a framework that can help you can meet the challenges! 

While unit testing would go a long way toward addressing the third and fourth risks, it would not help us address the first 2 risks.  We can ask business analysts (BAs) to help developers identify migration requirements, but we don’t have a repository for storing these requirements.  Even if we implement such a repository, a developer must still translate requirements (in whatever form they exist) into unit tests, which introduces the possibility of error.  Finally, the unit tests are not visible to the BAs, so they cannot rely on them for regression testing.

The Framework for Integrated Testing (FIT) seems to address all four of these risks quite adeptly.  Before I proceed, I should explain that FIT allows a non-developer to write requirements in tabular form.  FIT provides 3 types of test fixtures that can be used in a table:

  • A ColumnFixture is useful for business rules, as it is used to declare a set of inputs and expected output(s).  For example, you could use a column fixture to declare that a dwelling in a particular location built in 1996 should have a BCEGS of 99, but if it is built in 2004 it should have a BCEGS of 4.  As the Customer systems are replete with custom rules (such as underwriter referral rules), the ColumnFixture should prove very helpful.
  • A RowFixture is ensures that data are being stored and retrieved correctly from a data repository.  While I see no need to test the data layer’s reliability with respect to standard data such as dwelling address (it has proven quite reliable for other projects), the RowFixture could help us with data that are unique to Customer (such as subdivision).
  • An ActionFixture is used to simulate workflow requirements.  For example, a tabular ActionFixture could state that when a user enters a dwelling limit of $10k and presses “Continue”, a certain error message should appear; when s/he enters a dwelling limit of 300k and presses “Continue”, the system advances to the Quote Summary page; and if s/he enters a dwelling limit of 1100k, the system advances to the Qualification Questions page (due to consent to rate rules).

If we use the WinFitRunnerLite tool, a BA can construct the test data tables in Excel, which may be more intuitive than writing them in Word and saving as HTML.

A developer must write a test fixture in order to translate the test data into an actual test.  The test fixture will link to the domain, data, and controller/workflow libraries of the system under test, pass data from the test document’s tables to the appropriate methods, and evaluate the results against the BA-supplied expectations.  If we follow this approach, it will be impossible for a developer to embed workflow logic, rules, or domain logic in the UI (a big win!). 

One of the other advantages of FIT is that a BA can “own” the generation of requirements and tests, since they are maintained in a single location.  A BA can easily design the test scenarios that the system must pass; I’ve seen complex requirements in Excel spreadsheets plenty of times, so I have no doubt about the ability of our BAs to generate FIT scenarios.  On the other hand, how many BAs could write a unit test?

Using FIT can help answer many project management questions:

  • Developer: How have requirements for the system changed?  Answer: check the FIT document.
  • Developer: What are the requirements I should work on?  Answer: see which FIT tests have not yet passed.
  • BA: How close are we to completing the latest project milestone?  Answer: run the FIT tests and see how many tests have not yet passed.
  • BA: Do the latest changes contain any regressions?  Answer: run the FIT tests and see if any tests that used to pass have started to fail.

It is true that the FIT tests do not run against the actual UI.  I see this is a positive, as it will prevent the project team from falling into the “Smart UI” trap.  However, it also means that FIT, however useful I think it will be, is not a silver bullet; testers will still have to interact with the system’s UI.  

Nevertheless, I think FIT will prove very helpful for this project, and for our shop in general.  And since BAs have to write requirements and perform testing, and developers have to translate requirements into testable code anyway, using FIT should not be burdensome.

 

Posted on Tuesday, February 5, 2008 4:12 PM Testing & Debugging , Agile Methodologies | Back to top


Comments on this post: Why You Should Consider Using FIT

# Why You Should Consider Using FIT
Requesting Gravatar...
Chris, great post, FIT is a great tool to design and then test business logic.
Actually I also thought about how to translate FIT to test UI.
I did not find any good idea.

On a different note I created QuickUnit.net,
which is another kind of unit test framework to implement minimalists approach to test driven development. It was influenced by FIT.

Frederic Torres
www.InCisif.net
Web Testing with C# or VB.NET
Left by ftorres on Feb 06, 2008 3:01 PM

# re: Why You Should Consider Using FIT
Requesting Gravatar...
Frederic -

QuickUnit.net looks like an excellent tool for gradually integrating unit testing into an existing code base. It also brings the test into proximity with the actual method being tested, which improves documentation. However, it does not have the same goal as FIT. With FIT, we are unifying the requirements and the testing into a single document, which is not at all a concern of unit testing. In addition, FIT testing defines the behavior of the domain, controller, or data logic at its boundary with an external interface (typically a UI), whereas unit testing can be applied to any component or class within a system.

- Chris
Left by Chris Falter on Feb 20, 2008 8:49 AM

Your comment:
 (will show your gravatar)


Copyright © Chris Falter | Powered by: GeeksWithBlogs.net