I want a mock that returns 0 the first time, then returns 1 anytime the method is called thereafter. The problem is that if the method is called 4 times, I have to write:
mock.SetupSequence(x => x.GetNumber())
.Returns(0)
.Returns(1)
.Returns(1)
.Returns(1);
Otherwise, the method returns null.
Is there any way to write that, after the initial call, the method returns 1?
The cleanest way is to create a Queue and pass .Dequeue method to Returns
.Returns(new Queue<int>(new[] { 0, 1, 1, 1 }).Dequeue);
That's not particulary fancy, but I think it would work:
var firstTime = true;
mock.Setup(x => x.GetNumber())
.Returns(()=>
{
if(!firstTime)
return 1;
firstTime = false;
return 0;
});
Bit late to the party, but if you want to still use Moq's API, you could call the Setup function in the action on the final Returns call:
var mock = new Mock<IFoo>();
mock.SetupSequence(m => m.GetNumber())
.Returns(4)
.Returns(() =>
{
// Subsequent Setup or SetupSequence calls "overwrite" their predecessors:
// you'll get 1 from here on out.
mock.Setup(m => m.GetNumber()).Returns(1);
return 1;
});
var o = mock.Object;
Assert.Equal(4, o.GetNumber());
Assert.Equal(1, o.GetNumber());
Assert.Equal(1, o.GetNumber());
// etc...
I wanted to demonstrate using StepSequence, but for the OP's specific case, you could simplify and have everything in a Setup method:
mock.Setup(m => m.GetNumber())
.Returns(() =>
{
mock.Setup(m => m.GetNumber()).Returns(1);
return 4;
});
Tested everything here with xunit#2.4.1 and Moq#4.14.1 - passes ✔
You can use a temporary variable to keep track of how many times the method was called.
Example:
public interface ITest
{ Int32 GetNumber(); }
static class Program
{
static void Main()
{
var a = new Mock<ITest>();
var f = 0;
a.Setup(x => x.GetNumber()).Returns(() => f++ == 0 ? 0 : 1);
Debug.Assert(a.Object.GetNumber() == 0);
for (var i = 0; i<100; i++)
Debug.Assert(a.Object.GetNumber() == 1);
}
}
Just setup an extension method like:
public static T Denqueue<T>(this Queue<T> queue)
{
var item = queue.Dequeue();
queue.Enqueue(item);
return item;
}
And then setup the return like:
var queue = new Queue<int>(new []{0, 1, 1, 1});
mock.Setup(m => m.GetNumber).Returns(queue.Denqueue);
Normally, I wouldn't bother submitting a new answer to such an old question, but in recent years ReturnsAsync has become very common, which makes potential answers more complicated.
As other have stated, you can essentially just create a queue of results and in your Returns call pass the queue.Dequeue delegate.
Eg.
var queue = new Queue<int>(new []{0,1,2,3});
mock.SetupSequence(m => m.Bar()).Returns(queue.Dequeue);
However, if you are setting up for an async method, we should normally call ReturnsAsync. queue.Dequeue when passed into ReturnsAsync and will result in the first call to the method being setup working correctly, but subsequent calls to throw a Null Reference Exception. You could as some of the other examples have done create your own extension method which returns a task, however this approach does not work with SetupSequence, and must use Returns instead of ReturnsAsync. Also, having to create an extension method to handle returning the results kind of defeats the purpose of using Moq in the first place. And in any case, any method which has a return type of Task where you have passed a delegate to Returns or ReturnsAsync will always fail on the second call when setting up via SetupSequence.
There are however two amusing alternatives to this approach that require only minimal additional code. The first option is to recognize that the Mock object's Setup and SetupAsync follow the Fluent Api design patterns. What this means, is that technically, Setup, SetupAsync, Returns and ReturnsAsync actually all return a "Builder" object. What I'm referring to as a Builder type object are fluent api style objects like QueryBuilder, StringBuilder, ModelBuilder and IServiceCollection/IServiceProvider. The practical upshot of this is that we can easily do this:
var queue = new List<int>(){0,1,2,3};
var setup = mock.SetupSequence(m => m.BarAsync());
foreach(var item in queue)
{
setup.ReturnsAsync(item);
}
This approach allows us to use both SetupSequence and ReturnsAsync, which in my opinion follows the more intuitive design pattern.
The second approach is to realize that Returns is capable of accepting a delegate which returns a Task, and that Setup will always return the same thing. This means that if we were to either create an an extension method for Queue like this:
public static class EMs
{
public static async Task<T> DequeueAsync<T>(this Queue<T> queue)
{
return queue.Dequeue();
}
}
Then we could simply write:
var queue = new Queue<int>(new []{0,1,2,3});
mock.Setup(m => m.BarAsync()).Returns(queue.DequeueAsync);
Or would could make use of the AsyncQueue class from Microsoft.VisualStudio.Threading, which would allow us to do this:
var queue = new AsyncQueue<int>(new []{0,1,2,3});
mock.Setup(m => m.BarAsync()).Returns(queue.DequeueAsync);
The main problem that causes all of this, as that when the end of a setup sequence has been reached, the method is treated as not being setup. To avoid this, you are expected to also call a standard Setup if results should be returned after the end of the sequence has been reached.
I have put together a fairly comprehensive fiddle regarding this functionality with examples of the errors you may encounter when doing things wrong, as well as examples of several different ways you can do things correctly.
https://dotnetfiddle.net/KbJlxb
Moq uses the builder pattern, setting up the behavior of the mocks.
You can, but don't have to use the fluent interface.
Keeping that in mind, I solved the problem this way:
var sequence = myMock
.SetupSequence(""the method I want to set up"");
foreach (var item in stuffToReturn)
{
sequence = sequence.Returns(item);
}
Related
I read a few tutorial on Moq C# package but I still can't really understand what is Setup and Returns in Moq.
Example,
mock.Setup(p => p.GetEmployeebyId(1)).ReturnsAsync("JK");
Example 2,
mock.Setup(x => x.Save(It.IsAny<DeskBooking>())).Callback<DeskBooking>(
deskBooking =>
{
savedDeskBooking = deskBooking;
});
)
TL;DR: Setup = When, Returns = What
Whenever you write unit tests then you want make sure that a given piece of functionality is working as expected. But most of the time the functionality depends on some other components / environment / external source / whatsoever.
To make your test focused and replayable we need to use test doubles. These will replace your dependencies during the test. We can categorize the test doubles like this:
Dummy: simple code that returns bogus data
Fake: a working alternative which can take shortcuts
Stub: custom logic with predefined data
Mock: custom logic with expectations (interactive stub)
Shim: custom logic at run-time (replace static with a delegate)
Spy: interceptors to record calls
So, whenever you want to create a mock then you have to tell that under what circumstances how should the component behave. In other words when the function is called with a particular input then what should be the expected output.
In case of Moq you can use the Setup to define the when. And the Returns to specify the what.
Here is a simple example. Let's suppose you have the following function:
private IService service;
string MyMethod()
{
int number = service.GetNextNumber();
if(number % 2 == 0)
{
return "even";
}
else
{
return "odd";
}
}
Then you can write the following to test cases:
public void GivenAnEvenNumber_WhenICallMyMethod_ThenItShouldReturnEven
{
//Arrange
var serviceMock = new Mock<IService>();
serviceMock
.Setup(svc => svc.GetNextNumber())
.Returns(2);
...
//Act
var result = SUT.MyMethod();
//Assert
Assert.Equal("even", result);
}
public void GivenAnOddNumber_WhenICallMyMethod_ThenItShouldReturnOdd
{
//Arrange
var serviceMock = new Mock<IService>();
serviceMock
.Setup(svc => svc.GetNextNumber())
.Returns(1);
...
//Act
var result = SUT.MyMethod();
//Assert
Assert.Equal("odd", result);
}
So, as you can see we have used Setup and Returns to direct the control flow in each test case.
Your second example can be considered a Spy, because there you are recording the input for latter assessment.
In example 1
mock.Setup(p => p.GetEmployeebyId(1)).ReturnsAsync("JK");
sets up your mock so when GetEmployeebyId is called with a 1 as the parameter, the mock will return "JK".
In example 2
mock.Setup(x => x.Save(It.IsAny<DeskBooking>())).Callback<DeskBooking>(
deskBooking =>
{
savedDeskBooking = deskBooking;
});
when the Save method is called with any parameter of type DeskBooking, the lambda function will save the parameter in the savedDeskBooking variable. You can then test that you've saved the DeskBooking you expected.
I'm trying to unit test a method where a function is called in a loop. One of the parameters supplied to the method is a List<string>, declared outside the loop, that should be updated by each call that it is passed to.
I've been trying to mock this behaviour using some examples that I found on SO that involve updating the parameter inside of a Callback(), but this hasn't worked for me as expected.
Here is a short-hand example of the problem I'm having:
Method
public async Task DoSomething() {
var strings = new List<string>();
for(i = 0; i < 2; i++) {
var response = await _responder.GetResponse(i, strings);
//method adds a new string into the collection on each call
}
}
So to test this, I would need to mock both method calls, knowing that the string collection would be empty on one and contain one element on the other...
Test
public async Task TestDoSomething() {
var strings = new List<string>();
var mock = new Mock<Responder>();
mock.Setup(x => x.GetResponse(0, strings)) //mocks first iteration of loop
.ReturnsAsync(new Response())
.Callback<int, List<string>>((number, stringCollection) => {
stringCollection = new List<string> {"addedString"}; //this is where the problem occurs
strings = stringCollection;
});
mock.Setup(x => x.GetResponse(1, strings)) //mocks second iteration of loop
.ReturnsAsync(new Response());
//...
}
So at the point where I try to update the collection of strings inside the callback, studio highlights the parameter and gives me the warning The value passed to the method is never used because it is overwritten in the method body before being read.
The test fails because the setups are not matched, and trying to debug causes the test to crash and drop out.
Can anyone point me in the right direction here? Between the warning message and the fact that all the other examples of this stuff just use Returns rather than ReturnsAsync, I would guess that it's to do with the timing of updating the parameter.
Thanks in advance!
Not sure what exactly you want to test the method call or that values added to the collection.
But if you want to test that method was called, you can use Verify function like this -
mock.Verify(mock => mock.GetResponse(It.IsAny<int>(), strings), Times.Exactly(2));
PS. You should use It.IsAny<int>() cause first param obtain index from loop SO _responder.GetResponse(0, strings) calls only once and so on.
I'm writing a data access layer for my application and trying to mock out the CosmosDB SDK dependency for unit testing. I am using NUnit with NSubstitute and have come across the issue where I am trying to mock the return values for Container.GetItemQueryIterator.
I have successfully provided a mock feedIterator as a response for that call and a mock feedResponse as a return value for feedIterator.ReadNextAsync, but I cannot figure out how to inject any sort of values into the FeedResponse to test against
The code I'm trying to test looks like this:
var feedIterator = container.GetItemQueryIterator<T>(queryDefinition);
while (feedIterator.HasMoreResults){
result.success = true;
foreach (var item in await feedIterator.ReadNextAsync()){
list.Add(item);
}
}
My attempt at mocking out the dependencies like this (Simplified):
this.mockFeedResponse = Substitute.For<FeedResponse<T>>(this.mockApplicationList);
this.mockFeedIterator = Substitute.For<FeedIterator<T>>();
this.mockFeedIterator.ReadNextAsync().ReturnsForAnyArgs(Task.FromResult(this.mockFeedResponse));
this.mockFeedIterator.HasMoreResults.Returns(true);
Looking at the AzureCosmosDB SDK documentation, there seems to be a FeedResponse constructor for mocking that takes an IEnumerable as a parameter, but NSubstitute complains telling me it can't find this constructor when I attempt to pass in a list to use. Is there an alternative that I can feed some IEnumerable as a FeedResponse? Where am I going wrong?
I also managed the issue by mocking the GetEnumerator call on the FeedResponse mock. However, something to keep in mind is that if you just set mockFeedIterator.HasMoreResults(true), you'll end up in an infinite loop.
I solved that problem by using Moq's Callback method feature. I configured the HasMoreResults method to return true, and then setup a callback on the ReadNextAsync method to reconfigure HasMoreResults to return false. That way, it will drop into the while loop the first time, populate the return collection based on the mocked GetEnumerator method, and then exit the loop and return that collection to the test method.
var myItems = new List<MyItem>
{
new MyItem(),
new MyItem()
};
var feedResponseMock = new Mock<FeedResponse<MyItem>>();
feedResponseMock.Setup(x => x.GetEnumerator()).Returns(myItems.GetEnumerator());
var feedIteratorMock = new Mock<FeedIterator<MyItem>>();
feedIteratorMock.Setup(f => f.HasMoreResults).Returns(true);
feedIteratorMock
.Setup(f => f.ReadNextAsync(It.IsAny<CancellationToken>()))
.ReturnsAsync(feedResponseMock.Object)
.Callback(() => feedIteratorMock
.Setup(f => f.HasMoreResults)
.Returns(false));
var containerMock = new Mock<Container>();
containerMock
.Setup(c => c.GetItemQueryIterator<MyItem>(
It.IsAny<QueryDefinition>(),
It.IsAny<string>(),
It.IsAny<QueryRequestOptions>()))
.Returns(feedIteratorMock.Object);
You can mock ReadNextAsync to return a mock of FeedResponse that only has GetEnumerator() defined. The GetEnumerator of the List you create will then be passed through to the underlying implementation of the foreach.
The following example uses Moq, but you should be able to do something similar in your implementation.
var mockFeedResponse = new Mock<FeedResponse<Thing>>();
mockFeedResponse
.Setup(x => x.GetEnumerator())
.Returns(
new List<Thing>
{
new Thing(),
new Thing()
}.GetEnumerator()
);
For what it's worth - I worked around this by changing my code to access the Resource field on the FeedResponse received from CosmosDB. In my tests, I was able to then mock the return value for Resource and get the desired result.
I'm trying to mock a third party component for my tests.
The component can store a byte array, but has no property, only two methods to access it.
// simple demo code, _comp is an object of this component
byte[] val = new byte[] { 5 };
// write new value
await _comp.WriteAsync(val);
// read value
byte[] newVal = _comp.ReadAsync();
Now in my tests, I thought I could just Setup the WriteAsync method to change the Setup of the ReadAsync method to return the passed in values.
Mock<IComponent> comp = new Mock<IComponent>;
comp.Setup(x => x.WriteAsync(It.IsAny<byte[]>())).Callback<byte[]>(bytes =>
{
comp.Setup(x => x.ReadAsync()).ReturnsAsync(bytes);
});
But when I debug the demo code in my tests everything works well, the line with
comp.Setup(x => x.ReadAsync()).ReturnsAsync(bytes);
is called with the right values, but when the WriteAsync call returns I get a NullReferenceException in the demo code in the line
await _comp.WriteAsync(val);
I do not know what is null here, _comp and val are not.
I believe it is something deep within the Moq-framework, but I don't get any stacktrace info about that. Stacktrace only contains my demo code.
Am I doing something wrong here?
Or is it not possible to change a Mock-object from within one of its own callbacks?
I think, what I need could be done with a property, but unfortunately the component doesn't have one.
Store the written bytes in a local variable as a backing store for the mock. In the callback you set the value of the array so that it is available when used in the ReadAsync.
The WriteAsync is also an async method so it needs to return a Task to allow the async flow.
Mock<IComponent> comp = new Mock<IComponent>();
byte[] bytes = null;
comp.Setup(x => x.WriteAsync(It.IsAny<byte[]>()))
.Callback<byte[]>(b => bytes = b)
.Returns(Task.FromResult((object)null));
comp.Setup(x => x.ReadAsync()).ReturnsAsync(bytes);
Update based on comments.
In the comments it was mentioned that the WriteAsync return Task<bool>. While the condition of the return value is unknown based on what was provided in the OP, an example of have a condition based on the provided array can look like this
.Returns<byte[]>(b => Task.FromResult(b != null && b.Length > 0));
So for others who stumble upon this, my initial code works, but when the method will return something other than void, one must specify this.
Async methods return Task or Task<>, so the Setup code should be e.g.
Mock<IComponent> comp = new Mock<IComponent>;
comp.Setup(x => x.WriteAsync(It.IsAny<byte[]>())).Callback<byte[]>(bytes =>
{
comp.Setup(x => x.ReadAsync()).ReturnsAsync(bytes);
}).ReturnsAsync(true);
I'm trying to asssert that a method was called on a stub. The method I'm trying to assert was called takes an IEnumerable<string>. I don't care about the exact contents, but I just want to test that the count is a certain number. I can't get the assertion correct, I get
Rhino.Mocks.Exceptions.ExpectationViolationException : Bob.DoThings(collection count equal to 10); Expected #1, Actual #0.
I know that DoThings() is indeed being called... I just can't get the constraint correct..
var myBob= MockRepository.GenerateStub<Bob>();
var countConstraint = Rhino.Mocks.Constraints.List.Count(Rhino.Mocks.Constraints.Is.Equal(10));
// execution code....
Joe myJoe = new Joe(myBob);
myJoe.MethodThatShouldCallDoThingWith10();
myBob.AssertWasCalled(s => s.DoThings(null), o => Constraints(countConstraint));
I've also tried adding "IgnoreArguments" as a constraint. What am I missing?
The issue here is with deferred execution. It's not until the IEnumerable<string> is enumerated that the list of items is "built". Since Rhino.Mocks just records what gets called, it never "uses" the method arguments and therefore, the list is never built nor enumerated. As you've seen, adding a ToList() or ToArray() enumerates and builds the list so the test will pass if you use one of those methods.
One workaround is to grab the list that was passed to the method and do your check on that:
var list = (IEnumerable<int>) myBob.GetArgumentsForCallsMadeOn(b => b.DoThings(null))[0][0];
Assert.AreEqual(10, list.Count());
This test passes and doesn't require any changes to your code.
This problem was alredy reported Here. I've been able to reproduce this problem with the following Bob and Joe:
public interface Bob
{ void DoThings(IEnumrable<int> list); }
public class Joe
{
private readonly Bob bob;
public Joe(Bob bob)
{ this.bob = bob; }
public void MethodThatShouldCallDoThingWith10()
{
var values = Enumerable.Range(1, 100).Where(x => x > 0 && x < 11);
bob.DoThings(values);
}
}
It seems there's some problem in Rhino Mocks after all, when it comes to LINQ: either report the bug to Ayende or add ToList() in your production code (not really recommended)...