I've been secretly working on something... well, it's not that much of a secret... It's a new Fit Fixture for Given/When/Then acceptance tests (or BDD style tests). Andy Palmer and I have been writing it in what spare time we have...

Part of it involves finding classes (potentially written by someone else), instantiating them and returning them for use... Today we took the class that does that and refactored it to death... until it looked like this.

Firstly, my thanks to Gojko Adzic for giving such a rapid response on the FitNesse mailing list to help me solve the problem I encountered getting my .NET assemblies loaded in FitNesse .NET...

After at least 2 years of doing absolutely no .NET work, I started working with a .NET team this week, helping them to use FitNesse.

Trying to run my test for the first time, the FitServer.exe just wasn't finding my assembly... HelloFitNesse.dll

When doing Acceptance Test Driven Development, one of the things that people find hard to understand at first is the nature of an acceptance test.

In the process of teaching it over the last few days, combined with my own experience and some of the discussions during the Agile Alliance Test Tools workshop I've found another way of helping people to understand how to write 'good' acceptance tests.

One of the difficulties introducing FIT or FitNesse to teams is often helping them understand the applicability of the three core fixture table styles.

ActionFixture, RowFixture and ColumnFixture are useful as identifiers but aren't great at communicating how they are applied.

Instead, I suggest that the team think about the purpose of the test. Is it trying to communicate flow, structure or conditional characteristics.

Nat Pryce shares some valuable lessons in using FIT

Lessons include:

* Know your Audience
* Nobody in the Team "Owns" the Specifications
* Intersperse Explanatory Text
* Reuse Fixtures Between Many Specifications
* Refactor Fixture Classes Very Aggressively
* Refactor the Specifications
* Don't Drive Business Objects Directly

[textile]And a little help from CruiseControl... Check out "Jeffrey Palermo's solution":http://codebetter.com/blogs/jeffrey.palermo/archive/2005/09/13/131922.aspx

We created a new project in CruiseControl.Net to watch the wiki. Call it WikiWatcher. This project uses "filesystem" as it's source control to watch. We point this at the FitNesse directory, and CC.Net will react when any of the files there change. CC.Net then kicks of a Nant script, and that gives us all the power we need.

Cheers Jeffrey.

[textile]From the "AutAT Website":http://boss.bekk.no/boss/autat/ ...

AutAT -- An Eclipse Plugin for Automatic Acceptance Testing of Web Applications AutAT * is an open source Eclipse plugin, * makes test driven development of web applications easier, * contains a rich graphical editor for specifying how web-sites should function, * is written using the Eclipse Graphical Editing Framework (GEF),

[textile] Well guess it is nearly time to move up to the video ipod. I took another learning point off "James Bach":http://www.satisfice.com/ and had been using an "ipod":http://blackbox.cs.fit.edu/blog/james/archives/000198.html (the nano rather then a shuffle though) for podcast downloads of lectures on software testing and development.
Now I have discovered there are videos of testing talks out there - free on google video, tonight I came across this "gem":http://video.google.com/videoplay?docid=-7618420216108922950&q=software+testing