In your test project, add a class whose name ends with 'Tests'. The public methods are assumed to be tests. This is the 'default convention'.
Fixie has no built-in assertion library and never will. This example works when you use the third-party Should library.
Tell Fixie how to find your tests.
Let's say you prefer NUnit-style [Test] attributes. Tell Fixie what your tests look like, by including a custom convention in your test project. It'll supercede the default convention.
With this convention in place, Fixie will only recognize [Test] methods as tests.
Tell Fixie how (and how often) to construct your test classes.
Like xUnit.NET, Fixie's default is to construct one instance of your test class for each test. The zero-argument constructor is your setup, and Dispose() is your teardown.
Your custom conventions can specify whether construction should happen once per test method (like xUnit.NET) or once per test class (like NUnit). Additionally, you can specify how instances of your test classes should be constructed.
Tell Fixie where test method parameters come from.
By default, Fixie has no idea where test method parameters come from.
Your custom conventions can specify how to resolve test method parameters.
Tell Fixie what to do before and after each part of the test class lifecycle.
Your custom conventions can specify custom behaviors around each test case (like NUnit `[SetUp]` and `[TearDown]`), at the start and end of each test class instance (like NUnit `[TestFixtureSetUp]` and `[TestFixtureTearDown]`), or before and after each test class.