FIT can be used for both ASP.NET and WinForms applications.  This is a very good book according to Jeremy.

What’s wrong with traditional requirements

BAs create an English language spec doc.  Developers interpret the spec doc to build code.  Testers interpret the spec doc to write test plans.  Then bug volleyball begins.

This can:

• Ambiguity in requirements.  English language docs leave too much room for interpretation.
• Often lacking in fine grained detail.  This is a problem with English docs.
• Often users don’t know what they want until you are coding.
• Test plans are a duplication of spec docs
• Sequential development can lead to gaps in communications and understanding.  The handoffs create low fidelity.  Having devs, BAs and testers working at the same time can decrease efficiency.
• Slow feedback between coding and testing
• Missing requirements analysis detail.  These details can’t be expected to come out in high level requirements.
• Regression testing

How we want to work:

• Build exactly the right thing.

• Deliver working software in increments with rapid iteration

• never be more than X (5?) days away from shipping.  Not how long the iteration is.

• Optimize throughput of working software* Maximize our ability to accommodate changes
• Regression testing must be more economical

Moving to Executable Requirements

Reduce amount of bug volleyball.  Catch requirements bugs faster.  Make the requirements unambiguous.  Have way less churn.

Acceptance Test: “A formal test conducted to determine whether or not a system satisfies its acceptance criteria…..”  Ward Cunningham

Executable Requirements:

• Express the detailed requirements as automated acceptance tests

• Red/Green compliance

• force details out into the open
• use examples as requirements
• requirements that bite back* Get the tests out in front of development
• Give developers the ability to execute acceptance tests locally.  Bug count will drop dramatically.  Story TDD or Acceptance TDD will help to make us work faster.  More automated testing beyond nUnit.  Start out iteration with all the acceptance tests Red.  Once all are green and the iteration is over these tests move from acceptance to regression.  Your build can pass when acceptance tests fail (perhaps they aren’t implemented), but it can’t pass when the regression tests fail.

Tools:

• FIT (Framework for Integrated Tests)
• FitNesseDotNet (FitNesseDotNet.sourceforge.net)
• StoryTeller – Supercharged FIT testing for .Net (storyteller.tigris.org)
• FitNesse (fitnesse.org)

Fit tests work best for business rule testing.  It’s also good for flow based testing.  Can be used to test UI integration.  Jeremy is using it very successfully to drive WinForms.

What are the benefits of FIT testing and hot to realize them

Must be human readable and should turn into documentation as they’re created.  To make readable FIT (and Fitnesse) uses HTML with tables rows and cells.

Green Pepper is standing on the shoulders of Fit.  Green pepper is potentially cleaner. (www.greenpeppersoftware.com)

Write your tests with the actual prose of the requirements plus the testing tables.  It looks very clean.

Fit tests require both C# (or other) and HTML specifications?

Feedback loop with Fitnesse is not as fast as it is with Story Teller due to the migration of files to build servers.

The DoFixture is the single greatest advance in test automation history.  Allows flow based testing.  Can create your own domain specific language for testing.  Use to coordinate other Fixtures.  i.e. WinForms Screen Manipulation.

When you attack Fitnesse tests, make your tests as small as possible.  Bigger tests are more brittle.  Leave big tests manual.

Like good unit testing you need to have seams in your codebase to be able to implement this type of testing well.

On a replacement project you can:

• Retrieve the data created in the database by an action in the old application
• Run the new client, inputting the same values, and compare the data created at the database level by the old and new applications

TableLoaderFixture can be used to setup the data in the database as you need it.  This can help you get a solid starting point.

Fitnesse tests can be both for developers and BAs.

Best Practices

• Just in time acceptance tests

• Remember the tests are business facing

• ubiquitous language* very close collaboration between developers, testers and the customers

• write the tests together* favour declarative test grammars

• self-contained tests