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

[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!