I found a well-written set of tips on Concordion’s website about how to structure the relationship between specifications, test fixtures, and the domain code being tested.
Concordion - Hints and Tips
http://www.concordion.org/Technique.html
It offers good advice including “smells” and better alternative ways to solve problems. Even if you never use Concordion, it’s always good to find a well-articulated treatment of a topic. This definitely qualifies.
Here’s a sample of the solid advice:
Tips
- Write specifications, not scripts
- Specifications should be stable
- Evolve a domain-specific language
- Isolate behaviours
- Think “Given-When-Then”
Common Smells
- Existing specifications are often changed
- Lots of “execute” commands
- Complicated instrumentation
- Complicated fixture code
- Examples all have the same structure
Concordion appears to be a Concordion.NET”.
You can learn more about Concordion’s main functionality here:
http://www.concordion.org/
Concordion.NET is hosted on Launchpad:
https://launchpad.net/concordion-net
Jeffrey Cameron maintains the .NET port and offers several blog posts about how to get started.
I plan to read more about Concordion and similar tools (including FitNesse’s .NET-based spin-offs like fitSharp in hopes of finding a system that can allow collaborative editing of test cases and help me collect metrics about changes in test results over time (correlated with code changes and business decisions). If you know of any good options, please comment.