0

We are using Moq 4 for our unit tests, specifically controller unit tests. We are using Moq's Verify() method to make sure an error was logged. The problem is the tests can pass but then fail the very next run.

We are using Serilog for our logger.

The Action method looks like 

public IActionResult Index(){
    try{
         var data = _repository.GetData();
         return View(data);
    }catch(Exception e){
        Log.Error(e.Message);
    }
}

So the unit test is using 

_mockLogger.Verify(x=> x.Write(LogEventLevel.Error,It.IsAny<string>()));

mockLogger is setup in the test's constructor like 

var _mockLogger = new Mock<Serilog.ILogger>();
Log.Logger = _mockLogger.Object;
//...

and the repository is mocked to throw an exception when invoked.

When it fails, we are getting the error message

"Moq.MoqException expected invocation on the Mock at least once but was never peformed x=>x.Write(LogEventLevel.Error,It.IsAny<string>())"

Any Ideas?

Nkosi
  • 235,767
  • 35
  • 427
  • 472
IEnjoyEatingVegetables
  • 968
  • 3
  • 11
  • 30
  • 4
    It would be helpful if you created a real [MCVE]. Remove anything that's not necessary for the reproduction of your problem (I suspect the repository calls aren't necessary, possibly the try/catch etc) and show how you set up your logging, show your unit test etc. – mason May 01 '18 at 15:03
  • What is _mockLogger? A Mock, If its the replacement for Log, then are you sure _repository.GetData(); is throwing as you expect? Are you sure you are replacing Log with the mocked item correctly? – Jamie Pollard May 01 '18 at 15:04
  • The struggle there is the code is on my intranet computer and I have to manually type it all out, so no copy pasting :-/ – IEnjoyEatingVegetables May 01 '18 at 15:05
  • @mason -- you are correct :-| – IEnjoyEatingVegetables May 01 '18 at 15:07
  • 1
    Can you make sure (temporarily edit) _repository.GetData() to always throw an exception – Jamie Pollard May 01 '18 at 15:16
  • @JamiePollard _mockLogger is a Mock -- the repository is mocked to throw an exception – IEnjoyEatingVegetables May 01 '18 at 15:18
  • You're describing "is setup in the test constructor" but you're not actually showing it. Ideally for a MCVE, you would only have two sections of code in your post: the System Under Test (the action method) and the test itself. They'd be shown fully in context, but they'd be minimal enough that anything that isn't 100% necessary to reproduce your issue is not included. – mason May 01 '18 at 15:47
  • To strip this down to the minimal problem can you just create the Mock and assign at the top of your unit test (not in the constructor), change the whole try to remove the invocation of the repository mock to throw new ApplicationException(), then show your unit test calling the Index() method? – Jamie Pollard May 01 '18 at 15:54

1 Answers1

3

It's not entirely possible to see what the problem is from the posted code. And I appreciate how hard it can be to make a MCVE for this. So I'm going to take two guesses.

Guess 1: I suspect the cause of your issue is the use of statics in your code, specifically to do with the logger.

I suspect what's happening is that other tests (not shown in the post) are also modifying/defining how the logger should behave, and since the logger is static, the tests are interfering with each other.

Try redesigning the code so that the instance of the logging functionality is dependency injected into the class under test, using serilog's ILogger interface, store this in a readonly field and use that when you want to log.

Guess 2: Based on the part of the post which says "...setup in the test's constructor" you haven't said (or tagged) which testing framework you're using; but the handful that I've used prefer you to do this kind of thing in attributed methods rather than in the constructor of the test. For example, NUnit has OneTimeSetUp (before any of the tests in that class are run), SetUp (before each test in that class is run), TearDown (after each test in that class is run), OneTimeTearDown (after all of the tests in that class are run). It's possible that the constructors of your tests are being called in an order that you're not expecting, and which is not supported by your testing framework; whereas the attributed methods sequence is guaranteed by the framework.

Richardissimo
  • 5,596
  • 2
  • 18
  • 36