TUnit.Mocks - Feedback

[thomhurst]

Hey all - So TUnit.Mocks is now available as a beta package. You should be able to install it from IDEs once you've checked the allow pre releases checkbox.

I would appreciate people to try it out and if you have any feedback, good or bad, please let me know! :)

[Morasiu]

Hi. Just personal preference, but the syntax for mocks is long (like in the Moq). I prefer NSubtitute. It's more natural.

// TUnit Mocks
// Arrange — create a mock
var mock = Mock.Of<IGreeter>();

// Configure — set up a return value
mock.Setup.Greet(Arg.Any<string>()).Returns("Hello!");

// Act — use the mock object
IGreeter greeter = mock.Object;
var result = greeter.Greet("Alice");

// Assert — verify the result and the call
await Assert.That(result).IsEqualTo("Hello!");
mock.Verify.Greet("Alice").WasCalled(Times.Once);

 //vs NSubstitute
//Create:
var calculator = Substitute.For<ICalculator>();

//Set a return value:
calculator.Add(1, 2).Returns(3);
Assert.AreEqual(3, calculator.Add(1, 2));

//Check received calls:
calculator.Received().Add(1, Arg.Any<int>());

[Peter-B-]

Hello

Actually, this is really a matter of personal preference: I prefer the explicit setup used by Moq. You know at more places when you are dealing with a mock vs with a real object.

In my current code base with NSubstitute, I keep discovering tests where only only mocks interact without any real service being invoked at all. I'm not saying this is NSubstitute's fault - but clearly separating between mock configuration/validation and usage might make such instances more obvious.

On the other hand that is more verbose.

[thomhurst]

I think an edge TUnit has is that the object is different (a Mock rather than just T) - you can call the same methods on it because they're source generated. So there is still some differentiation between the config and the object

[Peter-B-]

You are right. That is a great advantage, since the type system and IDE will tell you what you are dealing with.

[Dmetriy]

It seems that merging the mock’s methods with internal implementation methods may not be the best design choice.

For example:

var mock = Mock.Of<ITest>();

public interface ITest
{
    int Engine { get; }
    int Engine_ { get; }
}

An interface like this can lead to compilation errors due to name collisions. While it is technically possible to work around them, this creates unnecessary friction for users and makes the behavior less predictable.

It might be better to keep these concerns separated — for instance, by exposing mock-related functionality through a dedicated Setup property, or by moving implementation-specific methods into a separate wrapper/helper object instead of adding them directly to the mock type.

This would reduce the risk of conflicts with user-defined members and make the API surface clearer and more robust.

[thomhurst]

Thanks for the feedback @Dmetriy ! I've been thinking about naming conflicts too.

An idea I had was to make them internal and just access them from a static helper like var invocations = Mock.Invocations(mockInstance) .

These more advanced APIs are used a lot less anyway than the standard Returns(...) and .WasCalled(...) etc.

[Dmetriy]

Hello! I'm currently planning to write tests using TUnit and looking for an AOT-friendly, source-generator-based mocking framework for a reflection-free testing stack.

I have a few questions:

1. While porting tests, I encountered a compilation error in the generated code when mocking a type that contains a method with an out parameter of a ref struct type (e.g. ReadOnlySpan<byte>).
   Is this a current limitation of TUnit.Mocks, or a bug in the source generator?

   Minimal example:

var mock = Mock.Of<ITest>();

public interface ITest
{
    void Do(out ReadOnlySpan<byte> buffer);
}

2. Do you see support for mocking interfaces that use static abstract members as something that is feasible or in scope, given the source-generator-based design of TUnit.Mocks?

3. From a design perspective, what are the main intended advantages or trade-offs of TUnit.Mocks compared to other source-generated mocking libraries (e.g. Rocks)?

[Dmetriy]

Thanks a lot for the quick update — I’ve tried the latest version and the out + ref struct scenario now compiles correctly!

One follow-up question: what would be the recommended way to assign a value to an out ReadOnlySpan<byte> parameter when setting up the mock?

Regarding static abstract members — that makes sense. I understand it may require deeper investigation, so I’ll keep an eye on updates.

As for the design perspective, I’m generally aiming for an AOT-friendly approach with strong compile-time guarantees, so it’s interesting to understand how TUnit.Mocks balances strictness and ergonomics.

[thomhurst]

Try something like this:

mock.TryGet("key")
    .Returns(true)
    .SetsOutValue("found-value");

[Dmetriy]

In my version I don’t see SetsOutBuffer(...) — I only have SetsOutParameter(...) available.

[thomhurst]

Hmm can you share some sample code so I can take a look?

[Dmetriy]

public class MyTests
{
    [Test]
    public async Task MyTest()
    {
        var mock = Mock.Of<ITest>();
        mock.Do().SetsOutBuffer(new ReadOnlySpan<byte>());
        await Assert.That(true).IsTrue();
    }
}

public interface ITest
{
    void Do(out ReadOnlySpan<byte> buffer);
}

[m-gasser]

As a user of Moq, I always disliked, having to specify those It.IsAny<TheExactType>() for all method parameters. Since TUnit.Mocks is source generated, I think it should be possible to come up with a more convenient API.

For example instead of this...

var equalityComparer = Mock.Of<IEqualityComparer<int>>();
var equals = equalityComparer.Equals_(Arg.Any<int>(), Arg.Is<int>(b => b > 0)).Returns((a, b) => a == b);
// ... some testing code ...
await Assert.That(equals).WasCalled(Times.Once);

... this might be an alternative:

var equalityComparer = Mock.Of<IEqualityComparer<int>>();
var equals = equalityComparer.SetupEquals((a, b) => a == b, if: (_, b) => b > 0);
// ... some testing code ...
await Assert.That(equals).WasCalled(Times.Once);

It is not necessary the best way to do it and it will need some refinement, but I think it is already better than the classical syntax.
A few points to think about:

• A nice property of this syntax is, that normal C# rules, that everyone knows, apply. For example if there is no overload conflict, lambda argument types do not have to be specified. However, if there is a conflict, everyone will naturally understand, that the fix is changing (a, b) => ... to (int a, int b) => ...
• Just MethodName(lambda) does not describe well, what happens. Probably something like SetupMethodName(lambda) or MethodNameReturns(lambda) is better. And as an upside, it will reduce naming conflicts (In the example above no more Equals_).
• Maybe the parameters of the mock method body lambda should not be the actual values, but wrappers instead. Then one might be able to write something like (a, b) => b > 0 ? a == b : SetupResult<int>.NotSetUp. The return value would be a discriminated union, so that either a result could be returned, or a marker that the setup does not apply in this case, or maybe even an assertion result?
• It might be a good idea to eliminate all the Verify-Methods and instead integrate it into the TUnit Assert API.

[m-gasser]

Thinking about it more, TUnit.Mocks does not have to look like Moq and NSubtitute at all. Being able to rely on source generation and and not having to be independent of the testing framework should lift quite some limitations.

Do we really need all those Arg methods? And .Callback()? Maybe both can be just C# code?
And can we put Asserts in there?

equalityComparer.SetupEquals(async (call, a, b) => {
    // Any code can be called here, no need for Callback()
    if(b > 0)
    {
        return call.ReturnsAlways(a == b);
    }

    if(b == 0)
    {
        // This would imply .WasCalled(Times.Once) and fail the second time.
        // However, it is probably hard to detect, if it was never called. 
        return call.ReturnsOnce(a == b);
    }
    
    return await Assert.Fail("Oops, b <= 0 is totally unexpected!");
});

Similarly for sequential setups:

equalityComparer.SetupEquals(await (call, a, b) => {
    yield return call.ReturnOnce(true);

    // On the second call, we expect a=5 and b=6
    await Assert.That(a).IsEqualTo(5);
    await Assert.That(b).IsEqualTo(6);
    yield return call.ThrowOnce(false);

    // For the next 5 calls, return true, even if there is only one yield.
    yield return call.Return(true, Times.Exactly(5));
});

Maybe this is not a good idea or it is not possible to implement this way. In that case I hope, it is at least a good inspiration 😀.

[thomhurst]

I've actually been looking at something similar this evening.

I honestly think your syntax is a bit too heavy.

I've been implementing a few improvements:

• Simple Any() call that can be used in the place of Argos
• Source generating method overloads with Func<T, bool> so you can pass a condition directly instead of an Arg

See here: https://tunit.dev/docs/writing-tests/mocking/argument-matchers#inline-lambda-predicates

[andrewimcclement]

Supporting inline lambdas is great.

[volkmnv]

I just found this and would like to use it, but I have a question.
I have a method returning a Task. With NSubstitute i could write the following:

service
    .Method(Args.Any<bool>())
    .Returns(
        Task.FromException(new Exception()),
        Task.CompletedTask,
        Task.FromException(new Exception()),
        Task.CompletedTask,
        Task.FromException(new Exception()));

How can I do the same thing with TUnit.Mocks?

[volkmnv]

Just tried the new APIs in 1.24.0-beta and they work just fine. Thanks!

[fubar-coder]

I really like TUnit.Mocks. Using "It"/"Arg" as filter is a great idea, love it! There is something I wish that'd be possible:

Let's assume that I have the following interface:

interface IMyService
{
  int DoSomething(int a, int b, int c, int d, int e, int f);
}

The way to mock this is:

var myServiceMock = IMyService.Mock();
myServiceMock.DoSomething(Any(), Any(), Any(), Any(), Any(), Any())
  .Returns(1);

And validation would look like this:

myServiceMock.DoSomething(Any(), Any(), Any(), Any(), Any(), Any())
  .WasCalled(Times.Once);

Do you notice the many "Any()"? I wish that there would be a way (maybe synthetic overload) that would allow:

myServiceMock.DoSomething(AnyAll())
  .WasCalled(Times.Once);

// or

myServiceMock.All.DoSomething
  .WasCalled(Times.Once);

[thomhurst]

@fubar-coder try the latest version with

myServiceMock.DoSomething(AnyArgs())
  .WasCalled(Times.Once);

[fubar-coder]

@fubar-coder try the latest version with

Thank you! I can confirm that it works as expected.

[vladt22]

It cannot yet mock methods with generics, can it? This does not work:

using TUnit.Mocks;

public interface IGreeter
{
    string Greet<T>() where T : class;
}

public class Class1 { }
public class Class2 { }

public class GreeterTests
{
    [Test]
    public async Task Greet_Returns_Configured_Value()
    {
        var mock = IGreeter.Mock();

        mock.Greet<Class1>().Returns("Hello!");
        mock.Greet<Class2>().Returns("Goodbye!");


        IGreeter greeter = mock;
        var result1 = greeter.Greet<Class1>();
        var result2 = greeter.Greet<Class2>();

        await Assert.That(result1).IsEqualTo("Hello!");
        await Assert.That(result2).IsEqualTo("Goodbye!");
    }
}

Works ok with NSubstitute.

[thomhurst]

@osa0805 Try v1.49

[vladt22]

Super! Works now, thank you.

[vladt22]

How do I return the value that was passed to a method? This does not work:

public interface IGreeter
{
    string Greet(string name);
}

public class GreeterTests
{
    [Test]
    public async Task Greet_Returns_Configured_Value()
    {
        var mock = IGreeter.Mock();

        var nameArg = Any<string>();
        // ???
        mock.Greet(nameArg).Returns(nameArg.Latest);

        IGreeter greeter = mock;
        var result1 = greeter.Greet("Hello!");
        var result2 = greeter.Greet("Goodbye!");

        await Assert.That(result1).IsEqualTo("Hello!");
        await Assert.That(result2).IsEqualTo("Goodbye!");
    }
}

[thomhurst]

Returns can pass you a lambda value of what it received. So you can do:

public interface IGreeter
{
    string Greet(string name);
}

public class GreeterTests
{
    [Test]
    public async Task Greet_Returns_Configured_Value()
    {
        var mock = IGreeter.Mock();

        mock.Greet(Any()).Returns(input => input);

        IGreeter greeter = mock;
        var result1 = greeter.Greet("Hello!");
        var result2 = greeter.Greet("Goodbye!");

        await Assert.That(result1).IsEqualTo("Hello!");
        await Assert.That(result2).IsEqualTo("Goodbye!");
    }
}

[vladt22]

Indeed, this works! How about more complex case. Lets say I want to return 2nd param:

public interface IGreeter
{
    string Greet<T>(T obj, string name) where T : class;
}

public class Class1 { }

public class GreeterTests
{
    [Test]
    public async Task Greet_Returns_Configured_Value()
    {
        var mock = IGreeter.Mock();

        mock.Greet(Any<Class1>(), Any()).Returns(input => input.???);

        IGreeter greeter = mock;
        var obj1 = new Class1();
        var result1 = greeter.Greet(obj1, "Hello!");
        var result2 = greeter.Greet(obj1, "Goodbye!");

        await Assert.That(result1).IsEqualTo("Hello!");
        await Assert.That(result2).IsEqualTo("Goodbye!");
    }
}

[thomhurst]

@vladt22 try v1.50 and doing .Returns((input1, input2) => input2);

[vladt22]

Works in 1.50! Great, thank you!

[vladt22]

Also I cannot mock IConfiguration. This does not compile:

using Microsoft.Extensions.Configuration;

public class MyService
{
    public MyService(IConfiguration configuration)
    {
    }
}

public class GreeterTests
{
    [Test]
    public async Task Greet_Returns_Configured_Value()
    {
        var service = new MyService(IConfiguration.Mock());
    }
}

with NSubstitute this works ok:

var service = new MyService(Substitute.For<IConfiguration>());

[thomhurst]

Thanks for reporting - Will take a look!

[abhisheksiddhu]

any way to globally move to strict mock instead of writing the same thing in each test. I have come across many scenarios where the loose mocking made the tests flaky. with strict mocks I get those failures much earlier, but with agents writing most of my tests, there's a real possibility that I miss the strict mocking in review and tests again become flaky.

[thomhurst]

@abhisheksiddhu try v1.50 and doing:

public class GlobalSetup
{
    [Before(HookType.TestDiscovery)]
    public static void Configure(BeforeTestDiscoveryContext context)
    {
        context.Settings.Mocks.DefaultMode = MockBehavior.Strict;
    }
}

[vladt22]

How would I match in case method has params modifier? This does not compile:

public interface IGreeter
{
    string Greet(params object[] keyValues);
}

public class GreeterTests
{
    [Test]
    public async Task Greet_Returns_Configured_Value()
    {
        var mock = IGreeter.Mock();

        // ???
        mock.Greet(Is(1)).Returns("Hello!");

        IGreeter greeter = mock;
        var result = greeter.Greet(1);

        await Assert.That(result).IsEqualTo("Hello!");
    }
}

[thomhurst]

Thanks looks like a missed edge case! Try v1.51 😄

[vladt22]

The https://tunit.dev/docs/writing-tests/mocking/verification#tunit-assertion-integration does not seem to be working. Example:

public interface IGreeter
{
    string Greet(string name);
}

public class GreeterTests
{
    [Test]
    public async Task Greet_Returns_Configured_Value()
    {
        var mock = IGreeter.Mock();

        mock.Greet(Any()).Returns("Hello!");

        IGreeter greeter = mock;
        var result = greeter.Greet("Alice");

        mock.Greet(Any()).WasCalled(Times.Once);
        // this does not compile
        //await Assert.That(mock.Greet(Any())).WasCalled(Times.Once);
    }
}

[thomhurst]

Try v1.51 😄

[vladt22]

Something is wrong, you may have posted wrong version because with my copy of v1.51 it still does not compile as well as case above with params.

[thomhurst]

Have you got the TUnit.Mocks.Assertions package installed?

[vladt22]

No I did not, the documentation did not mention the need to install it. With it it works. 👍

May I ask - why another package? It's tiny, feels like should be shipped with tunit.mocks..

[thomhurst]

The assertions and mocks libraries are completely separate, and can be used one without the other (neither even need the TUnit basic framework to work). So it's a package that bridges the two together

[Zarpyk]

TUnit.Mocks is only for .net 10? On the documentation say it require C#14 but the Nuget show it can be used on .net 8.

[thomhurst]

If you have a modern sdk installed, you should be able to compile with c#14 features even for
.net 8

[Copper0292]

I'm trying to setup a multi-interface mock with behavior. How can I mock behavior on the second interface?

var dbContext = Mock.Of<DbContext, IInfrastructure<IServiceProvider>>();
dbContext.Instance.Returns(...); // Instance is a property of IInfrastructure
// CS1061: 'Mock<DbContext>' does not contain a definition for 'Instance'...

If I try to cast it to IInfrastructure<IServiceProvider>, it stops being a mock and executes the getter for Instance.

If I try to cast it to Mock<IInfrastructure<IServiceProvider>>, it gives an error message saying that can't convert from Mock<DbContext> to Mock<IInfrastructure<IServiceProvider>>.

I'm comming from NSubstitute:

dbContext = Substitute.For<DbContext, IInfrastructure<IServiceProvider>>();
((IInfrastructure<IServiceProvider>)dbContext).Instance.Returns(serviceProvider);

[thomhurst]

@Copper0292 Can you try v1.54