I’m always looking around at frameworks/libraries etc. to see if they enhance my development experience or offer new tools/capabilities that could be of use. I’m not wholly sure how I came across Fixie, but I wanted to check it out to see what it had to offer.

Introduction

Fixie is a convention based unit testing library, think NUnit or xUnit but without attributes.

It’s amusing that after re-reading the sentence above, I totally missed the irony that Fixie is really more of a throw back to jUnit with it’s convention based testing than the .NET equivalents with their attributes.

I’m not usually a big fan of convention based libraries, but there’s no doubt that if you’re happy with the convention(s) then code can look pretty clean.

The coolest thing with Fixie (well it’s cool to me) is that you simply add the nuget package to your solution, but don’t need to add a using clause that references Fixie (unless you wish to switch from the default conventions).

Fixie is immediately (or near as immediately) recognized by the Visual Studio Test Runner, but Resharper’s test runner, sadly, does not work with it “out of the box” (I believe there is a Resharper test runner, but I’ve not tried it and it didn’t appear in their extension manager, so I’m not sure what the state is of this at the time of writing.

Default Convention

The default convention is that your test class name is suffixed with the word Tests and methods can be named anything, but must return either void or async and be public, i.e.

public class MatrixTests
{
   public void AddMatrix()
   {
      // test based code
   }

   public async Task SubtractMatrix()
   {
      // test based code
   }
}

I’ve purposefully not written any assertion code because, Fixie does not supply any. Such code should be supplied using the likes of Should, Shouldly, FluentAssertions etc.

Custom Convention

Fixie gives us the tools to define our own custom convention if we want to change from the default. This includes the ability to not only change the naming conventions but also to include attributes to mark tests (like NUnit/xUnit uses). In fact, with this capability Fixie can be used to run NUnit or xUnit style tests (as we’ll see later). For now let’s just create our own test attribute

AttributeUsage(AttributeTargets.Method)]
public class TestAttribute : Attribute
{
}

So this attribute is only declared on methods. To implement a new convention we simple create a class derived from Fixies.Convention, for example

public class TestConvention : Convention
{
   public TestieConvention()
   {
      Methods.HasOrInherits<TestAttribute>();
   }
}

so now our tests might look like this

public class MatrixTests
{
   [Test]
   public void AddMatrix()
   {
      // test based code
   }

   [Test]
   public async Task SubtractMatrix()
   {
      // test based code
   }
}

So in essence, using Fixie, we could create our own test framework (of sorts) and using (as already mentioned) Should, Shouldly, Fluent Assertions etc. libraries to handle asserts. However, I’m sure that’s ultimately not what this functionality is for, but instead allows us to define our own preferred conventions.

See also Custom Conventions

NUnit & xUnit Convention

I mentioned that we could use Fixie to execute against other testing frameworks and on the Fixie github repository, we can find two such convention classes (and support classes) to allow Fixie to run NUnit or xUnit style tests.

See NUnit Style and xUnit Style.

I doubt the intention here is to replace NUnit or xUnit with Fixie as obviously you’d need to support far more capabilities, but these convention repositories give a great overview of what can be done on the Fixie convention front.