Picture the scene

It's a bright spring morning... We're writing tests for a class called MySystem. It uses a service, somewhat surreptitiously named MyService to do its work, and the necessary functionality has been surfaced through an interface:

public interface IMyService
{
    int ClientId { get; }
    string Echo(string text, TimeSpan timeout);
}

The MySystem class we want to test has an IMyService parameter in its constructor, and we could pass it a real MyService instance. There are only two problems.

1. The MyService has a number of dependencies of its own, so constructing an instance is not trivial.
2. It makes real http calls over the network and depends on an external service to function. Also we want our tests to be lightning-fast, and don't want to take the time to do a round-trip over the network.

The solution of course is to create a mock - our own implementation of the IMyService interface - and pass that to the MySystem constructor. Mocklis not only helps to do this. It does it in a way that lets us fine-tune the behaviour of the Mock on a case-by-case basis. How? Read on.

You create an empty class implementing the interface(s) you need, and add a [MocklisClass] attribute.
The Mocklis Mock Generator implements the interfaces explicitly and provides 'Mocks' for adding behaviour.

[MocklisClass]
public class MockService : IMyService, IDisposable
{
    public MockService()
    {
        ClientId = new PropertyMock(this, "MockService", "IMyService", "ClientId", "ClientId");
        Echo = new FuncMethodMock<(string text, TimeSpan timeout), string>(this, "MockService", "IMyService", "Echo", "Echo");
        Dispose = new ActionMethodMock(this, "MockService", "IDisposable", "Dispose", "Dispose");
    }

    public PropertyMock ClientId { get; }
    int IMyService.ClientId => ClientId.Value;
    public FuncMethodMock<(string text, TimeSpan timeout), string> Echo { get; }
    string IMyService.Echo(string text, TimeSpan timeout) => Echo.Call((text, timeout));
    public ActionMethodMock Dispose { get; }
    void IDisposable.Dispose() => Dispose.Call();
}

Notice that every interface member is explicitly implemented and paired up with a public property.

When writing tests you add different types of behaviour to the public properties of your mock class instances.

• Control: Define how your mocks should behave when called (using e.g. Return, Throw, and Func steps)
• Verify: Check that your mocks were called with the expected parameters (using e.g. Record steps)

// Create an instance of the mocklis class
var mockService = new MockService();

// Return values or throw exceptions (first read returns 42, subsequent ones throw)
mockService.ClientId
    .ReturnOnce(42)  
    .Throw(() => new InvalidOperationException("connection lost"));

// Record data during the test, and "Calculate" responses to function calls
mockService.Echo
    .RecordBeforeCall(out var timeouts, p => p.timeout.TotalSeconds)
    .Func(p => $"You sent '{p.text}'!");

// Finally add the mock to the system we want to test
var systemUnderTest = new MySystem(mockService);

This is of course just scratching the surface. Check the documentation for full details...

Mocklis helps you write your tests

Mocklis was designed to make the most of Visual Studio Intellisense:

• Visual Studio suggests compatible (be they built-in, your own, or third-party) steps when you add behaviour to your mocks.
• Names of parameters are carried over to your mocks and are available when setting up behaviour.

Nothing in the Mocklis Library is internal. If a helper class was used in a Mocklis built-in step, it's available to you when you write your own.

Mocklis helps you debug your tests

Mocklis generates source code. You can set breakpoints and use your existing debugging tools and skills to find out what's going on.

The Mocklis libraries are Source Linked debug builds. You can step straight into the Mocklis source code from your tests.

Mocklis has built-in logging. If you want to know how a step is interacted with, add a .Log() step just before it, and all interactions will be written to the console. Pass an ILogContext to the Log step to send data to other places such as Serilog or the xUnit ITestOutputHelper.

And( much)+ more - here's some favourites...

• Mocklis lets you mock generic interfaces and interfaces with methods that introduce new type parameters.
• The inheritance hierarchy is yours to dictate. Mocklis classes can inherit from other classes, and will avoid name clashes and introduce constructors as necessary.
• Conditional steps allow simple branching allowing your mocks to be more flexible, for instance to log only when certain conditions are met.
• Mocked events, properties and indexers can be set up to remember any data (or event handlers) written to them.
• Mocklis' verification classes lets you check a number of conditions on your mocks and assert them in one go, getting a full report of everything that didn't go to plan.

Thank you for reading! If you want to give Mocklis a try, find the Packages on Nuget, and some more in-depth documentation here. Then there's of course the GitHub project where you can get the source code as well as help and fixes for any issues that you might find.

Happy Testing!