Set Strict as default MockBehavior

[jerone]

Is it possible to set a default MockBehavior for the whole test project? With ModuleInitializer for example.

Currently, I have to manually define MockBehavior.Strict on all mocks.
But I want all my tests to be Strict by default.

[kzu]

Easiest way would be to define your own mock factory method, like CreateStrict<T> which does that (and potentially other default setups) for you. Would that work?

[jerone]

Creating an extra method still allows other from the team to ignore the strict behavior and use the default loose.

I really like the way Verify works with global static settings using a Module Initializer, where you can define default settings for all tests.

Pseudo suggestion:

public static class TestModuleInitializer
{
    [ModuleInitializer]
    public static void Initialize()
    {
        // Always use strict.
        MockSettings.UseMockBehavior(MockBehavior.Strict);
    }
}

[kzu]

Anyone on the team could still ignore that setting and change it, so how is that different? i.e. they could invoke the same method elsewhere. FWIW, you could create an analyzer for your org that simply forbids that usage.

[jerone]

Anyone on the team could still ignore that setting and change it, so how is that different?

Changing the default behavior in the Module Initializer is not something that would go unnoticed (in review or by policies).

It's more about the default behavior. Adding strict is currently only opt-in per mock and easily forgotten by developers. I prefer to have it the global default, and in rare cases have it explicitly opt-out to the loose behavior.

Analyzers are too strict and an overkill for one global default value.

[kzu]

Creating an extra method still allows other from the team to ignore the strict behavior and use the default loose.

Analyzers are too strict and an overkill for one global default value.

Those seem like conflicting goals. In any case, it's an interesting suggestion, but I'm not that fond of global static state. It's an interesting design choice in Verify. Might consider it for v5 🤔

[GillesTourreau]

@jerone We developed PosInformatique.Moq.Analyzers to check that all our Mock instance are defined to MockBehavior.Strict.

The rule PosInfoMoq1001 check the new Mock<T> declaration if the developer have defined the MockBehavior.Strict mode. Also, there is a Visual Studio fixer, which allows you to fix the MockBehavior.Strictto all thenew Mock` instantiation at the document, projects or solution level.

The last NuGet package of this analyzer can be found here: https://www.nuget.org/packages/PosInformatique.Moq.Analyzers/.

Anyway I am agree with you, it should be a "global setting" to define the default MockBehavior to apply for all the unit tests.

[jerone]

@GillesTourreau Awesome analyzer. Very useful. 👍

Finally had time to test it myself, and the PosInfoMoq1001 rule does exactly what was suggested earlier.

Maybe not the right place here, but I do have some feedback (I could created issues on the repo if preferred).

1. Rule PosInfoMoq1002 sometimes refers sometimes to a markdown file and other times to an html page.
   

2. Would it be possible to exclude Microsoft.Extensions.Logging.ILogger from rule PosInfoMoq1003. SUT's can contain loads of loggings (if done correctly), and using It.IsAny<>() for it's argument is the only way to not create many many different setups.

3. To keep tests clean and clear, I moved all mock setups to a so called "fixture" or "builder", in re-usable methods. In the tests I can than call those methods, instead of repeating the mock setups in every test. The analyzer however, is throwing PosInfoMoq1002 warnings on these fixtures when it detects Verifiable() without Verify(), because those are not part of the fixture, but are present in the actually tests. Example fixture, example test. Is this a bug or is there a way to exclude fixture from this warning?

[GillesTourreau]

@jerone Thanks for your feedback.

You can talk and submit issues and improvements in the issues/discussions of the related Github project.

For the ILogger it is very hard to mock, we have developed the following library PosInformatique.Logging.Assertions which allows to easily test / assert the log messages (specially the templated messages with arguments). Maybe you can have a look on it...
I will think if I can add a .json settings or something like that to define the interfaces mocked to exclude by the analyzers...