Best way to install a test with Moq

I mocked moq for a while and always did things like this:

Suppose the behavior I want to test is that classUnderTest.DoSomething () calls l.Fatal ("My test message") once.

//arrange mockLogger.Setup(l => l.Fatal("My test message")); //act classUnderTest.DoSomething() //assert mockLogger.Verify(l => l.Fatal("My test message"), Times.Once()); 

It seems to me that the test call is always a repeat of the installation, with the exception of the Times parameter. I would really like to know what others are doing, even with blurry frameworks. Is there a better way to do this?

+4
source share
4 answers

You only need to configure the Mock object if you really need to control the behavior of what it does, for example, return material:

 _mockRepo.SetUp(m => m.DoStuff()).Returns(someObject); 

or do an exception:

 _mockRepo.SetUp(m => m.DoStuff()).Throws(new SomeExceptionType()); 

I assume that in your example, you are passing the layout of the logger object to some other object that is under testing, in which case deleting the installation call will have no effect, since the equivalent setup will only be done by creating the Mock object.

Edit

 public class Dude : IDude { private IAirSupport _support; public Dude(IAirSupport support) { _support = support; } public void Advance(Place place) { if(place.IsUnderAttack) { _support.CoveringFire(place); MoveAndFire(place); } } } 

To make fun of it:

 var support = new Mock<IAirSupport>(); var dude = new Dude(support.Object); var place = new HotSpot { IsUnderFire = true }; dude.Advance(place); support.Verify(m => m.CoveringFire(place), Times.Once()); 

That's all you need - check if all the hard work is there, there is no reason to call the settings.

+4
source

I agree with your feelings that it feels repetitive. However, in this particular case, I do not think you need to call Setup() since you are not returning anything. I usually call Setup() if I need to assert something based on the returned object.

I recently started using AutoMocking through a structural map, which prompted me to write a few shortcut / utility tags in the base class to access the automatically generated mocks. Then I was able to write a shortcut to call Verify() . This can save you a keystroke or two ... http://evolutionarydeveloper.blogspot.co.uk/2012/10/automock-with-structuremap-and-moq.html

+2
source

Try rebuilding your test as follows

  //arrange var mockLogger = new Mock<ILogger>(); var classUnderTest = new Foo(mockLogger.Object); //act classUnderTest.DoSomething(); //assert mockLogger.Verify(l => l.Fatal("My test message"), Times.Once()); 

This way you do not need duplicate statements or duplicate test data. In principle, I suggest either severely mocking the expected calls in advance using Setup , or using Verify syntax. I personally like the validation syntax more, because what is indicated is very clear.

+1
source

I argue that a lot of tests seem to be repetitive, but I don’t see how everything can be done much easier than you describe.

All unit tests follow the pattern: setup-execute-assert (at least good ones). This is exactly what your example does gracefully. You can state how you tuned in and how you claim, but you did each in one line of code and find a method that is difficult to do.

0
source

Source: https://habr.com/ru/post/1447932/


All Articles