FAQ for Programmers

How to do some processing before and/or after a fixture does its work:

• See DoFixture.SetUpTearDown

How to keep the HTML tags within a table cell, as they're important to the test:

• See ^KeepTags

Flow style with DoFixture doesn't work when I use an Import table

• That's because the fixture of the first table of a storytest has to be a DoFixture for flow to be used.
• However, there's no need for the Import table in flow style, because there's no need to mention fixture names after the first one with DoFixture

What's the point of removing fixture names?

• They add technical complexity to the storytests that are best hidden away from customers who read/write storytests
• It's then possible to substitute different fixtures without having to change the storytests

What's the point of substituting fixtures?

• The same storytests can be used to test a system at different levels
• Some fixtures are used to test the system under test directly at the domain layer
• Other fixtures could have some extra code to instead test the system through a UI or some other interface
• Some fixtures could generates user documentation from some of the storytests

My tests used to pass, but they fail with the latest FitLibrary

• Here's one possibility, if you've been using parse delegates:
• In the latest version, all registered parse delegates are cleared at the end of a test, to avoid potentially confusing interactions between tests (test indepedence is a fundamental principle of storytesting).
• Perhaps your tests previously depended on this interaction?
• If so, you'll need to ensure that parse delegates are registered for each test.
• That's easy if you use the same (DoFixture) class to start all your tests: simply register the parse delegates in the constructor of the class. That is, don't do it in a static { ... } block.

• Copyright (c) 2004, 2005, 2006 Rick Mugridge, http://www.rimuresearch.com
• Released under the terms of the GNU General Public License version 2 or later.