For context, this is a c# project, and we’re using VS.Net, NAnt, and !SLiNgshot to build, along w/ the usual suspects:
NUnit, !CruiseControl.Net, etc.

Directory Structure——
We have a directory structure that looks like :

• doc/
• Iteration1/
• .html – all tests associated w/ a story
• .html
• Iteration2/
• .html
• Iteration3/
• stories.html – list of all stories in an !AllFiles like fixture
• lib/
• src/
• project 1/
• project 2/
• fit/
• run.aspx – copied from nfit
• custom fixture 1.cs – fixture used in a fit test
• custom fixture 2.cs
• project 3/
• foo.sln – solution file

We’ve argued a lot over what the structure of the source should look like on a .net project, and our current solution is a src dir, inside of which is one dir for each project and a solution file. It’s flat and easy to see where everything is.

All the FIT tests go into the doc dir. fit is a VS web project that references all the other projects, along w/ the FIT dll’s. It includes all the fixtures our tests will need and the run.aspx file from NFit.

Running FIT Dynamically——
We’ve found it totally necessary to be able to run fit tests dynamically in addition to
running them from command line. Ward has his run.cgi on http://fit.c2.com/ to let you click ‘run’ on a fit test. I’ve just checked in Run.aspx into NFit which will let you do the same thing.

This is how we use it:

We have 2 webshares. */doc* points to our ‘doc’ directory and holds all the tests. */fit* points to our ‘src/fit’ directory and holds our copy of Run.aspx along w/ all the code our tests run against. We put a run link at the top of each test that points to ‘/fit/run.aspx’, and when we browse our tests we do it through our local IIS using something like ‘http://localhost/doc/stories.html’.

Because fit is just another project along w/ all our other projects in VS, we get linking,
debugging, and building for free inside and outside visual studio.

Structuring FIT Tests——
When you’re writing so-called ‘acceptance tests’, it’s important to remember that there are several different missions of testing and types of tests to achieve them. The way you structure your tests should reflect this, see default.WhatAboutAcceptanceTesting

In the doc directory, we group our tests in files by the story they test against, and the stories by the iterations they are completed (or scheduled to be completed) in. This of course makes the assumption that all tests “belong” to one and only one story. Up until now that’s been okay, we’ll probably add another place to put tests when and if that becomes a problem. It has been good to teach our team to think about testing functionality in terms the customer can see.

Now we could just run all our tests automatically, but we wanted one page that everyone could
go to to see our teams status. So we take the spreadsheet of stories that our client keeps complete with
their points, their iteration, and their status (done or not). And we point to it with an aspx page to
provide an html view that fit can run against. So when you go to http://localhost/doc/, you see a table for
every iteration, each of which contains all the tests in that iteration. Only ones that have been marked
done in the spreadsheet get run.

So we have one page that tells you the status of all stories we’ve ever done. And it tells you how we’re doing
on the current iteration as well – along w/ our velocity of course ——How about if my return value is an XML document, how does FIT deal with that. How do I pass two parameters to a method.

TIA