I have stubbed a method on an interface and want to see with what parameter it was called, but this method is called several times and I'd like to be able to inspect the parameter of each call. is there like a stack of the history of calls made to the stub that I can inspect?
my scenario is something like this:
myStub.AssertWasCalled(stub => stub.SomeMethod(Arg<ISomeInterface>.Matches<ISomeInterface>(p => p.Mode == Mode.SomeEnum)))
You can use GetArgumentsForCallsMadeOn.
GetArgumentsForCallsMadeOn returns a two dimensional array of objects so you will need to cast to get to the types you are expecting.
It works like this:
public interface IDependency {
int DoSomething(SomeComplexType someComplexType,
int someInteger);
}
IList<object[]> argumentsSentToDoSomething =
dependency.GetArgumentsForCallsMadeOn(x => x.DoSomething(null, 0));
Related
My test method looks like this:
public static List<Something> Generator() {
return A.GenerateObjects();
}
[Test, TestCaseSource(nameof(Generator))]
public void DoSomething(Something abc) {/*do something*/}
This code works very well and generates for each object in the list an unit case.
I want to include another parameter in the method like:
public void DoSomething(Something abc, string def)
I've tried it with these lines but it didn't work:
public static object[] Case =
{
new object[]
{
A.GenerateObjects(),
someStrings
}
};
Maybe iterate the list with an loop function instead of invoking the method (GenerateObjects()) directly? I also don't understand how Nunit can recognize the objects from the list directly with only TestCaseSource(nameof(Generator))
Thanks in advance!
You can return an IEnumerable of TestCaseData like this:
public static IEnumerable<TestCaseData> Generator()
{
yield return new TestCaseData(new Something { SomeValue = "Hi" }, "Foo").SetName("FirstTest");
yield return new TestCaseData(new Something { SomeValue = "Bye" }, "Bar").SetName("SecondTest");
}
[Test]
[TestCaseSource(nameof(Generator))]
public void DoSomething(Something abc, string def)
{
Console.WriteLine($"{abc.SomeValue},{def}");
}
The SetName is optional, just if you want a more meaningful name than the default one it makes up.
I also don't understand how Nunit can recognize the objects from the
list directly with only TestCaseSource(nameof(Generator))
Nunit notices the TestCaseSource attribute on the test method, and then uses reflection to invoke the "Generator" method. (Nameof is just sugar, the compiler substitutes it with the actual name when you build it). Every TestCaseData object that is returned is another test case. In my example above the tests will be run twice. FirstTest will have a Something instance where SomeValue is set to Hi and a def string of Foo. SecondTest will have a Something instance where SomeValue is set to Bye and a def string of Bar.
Your initial test takes a single argument of type Something. Apparently, A.GenerateObjects() returns some sort of IEnumerable of those objects - you don't show the detail. Because the test is a single-argument method, that works. NUnit provides a special case for single argument methods, which is very forgiving and will accept arrays of objects or of the type that is required and generate the test cases for you itself.
However, for multiple arguments, it's up to you to return a set of test cases from your method yourself. As you probably know, the arguments to a method in C# are in the form of an object[] containing the arguments, like new object[] { aSomething, "astring" }.
Assuming that you have specific strings that need to be associated with each object, it's up to you to make that association. How to do that depends on the details of what you are trying to do.
Do you have a list of strings, which you want to associate with the list of objects one for one? In that case, stop using [TestCaseSource] and use [ValueSource] or [Values] on each parameter of the test method. Apply [Sequential] to the method to cause NUnit to match up the objects and strings one for one. Here's an example...
[Test, Sequential]
public void DoSomething(
[ValueSource(typeof(A), nameof(GetObjects)] Something abc,
[Values("string1", "string2", "string3")] string def)
{/*do something*/}
This is just one way to do it. I've had to do a bunch of guessing as to what data you have readily available and what you are trying to do. If this approach doesn't work for you, please fill in the blanks a bit and I'll edit the answer.
I am mocking out a wrapper we use for some enterprise library calls. All was well in the world, my tests passed and the actual code worked!
However I then extended the functionality, and verified the tests all still passed. Bingo - they did. However they didn't in the real world because there is an expectation that
InitialiseDBCommand(string, commandtype)
will be called before
AddCmdParameter(string, dbtype, object)
So like a good boy, the first thing I want to do is write a test that exhibits this behavior and expects an exception to be thrown.
What I need is to rig up AddCmmParater to throw an exception IF InitialDBCommand has not been called with any string.
I figure I could do this with a call back, but it feels like moq'ing a method call sequence (not a method return sequence) ought to be there.
Something like
iDataAccessHelper.Setup(s=>s.AddCmdOutputParameter(It.IsAny<string>(),
It.IsAny<DbType>(),
It.IsAny<int>()))
.When(w=>w.InitialiseDBCommand(etc etc)
.Throws<NullReferenceException>()
Any pointers?
Well if you simply want to test if 2 methods are called in the correct order, one way to do it would be to add a counter that is incremented each time one of the methods is called and then check if it's the correct number. Here is one answer that describes it.
Here is how I'd write it for your scenario:
[Test]
public void TestingCallOrder() {
int counter = 0;
var mockDataAccessStuff = new Mock<IDataAccessStuff>();
mockDataAccessStuff.Setup(x => x.AddCmdParameter(It.IsAny<string>())).Callback(() => {
Assert.AreEqual(counter, 0);
counter++;
});
mockDataAccessStuff.Setup(x => x.InitialiseDbCommand(It.IsAny<string>())).Callback(() => {
Assert.AreEqual(counter, 1);
counter++;
});
// more of the same
var myClass = new ClassThatImTesting(mockDataAccessStuff.Object);
myClass.DoWork();
// make sure both methods are called at least once ...
mockDataAccessStuff.Verify(x => x.AddCmdParameter(It.IsAny<string>()), Times.Once());
mockDataAccessStuff.Verify(x => x.InitialiseDbCommand(It.IsAny<string>()), Times.Once());
}
I think that's a very clean and readable way to write the test.
There is a library that extends Moq to add this functionality called Moq Sequences. Which from their examples looks like
using (Sequence.Create())
{
mock.Setup(_ => _.Method1()).InSequence();
mock.Setup(_ => _.Method2()).InSequence(Times.AtMostOnce());
...
// Logic that triggers the above method calls should be done here.
...
}";
It asserts that Method1 is called before Method2
I have a situation where I have an interface that exposes a method returning an IEnumerable
interface IIEnumerableProvider<T>
{
IEnumerable<T> GetData();
}
I need to be able to create a stub of this that supports being called once, and when the resulting RangeIterator is enumerated a first time returns values defined by the stub, if enumerated a second time it will return a different set of values and so on for further enumerations.
Stubbing for a single enumeration is easy enough:
var stub = MockRepository.GenerateStub<IIEnumerableProvider<int>>();
stub.Stub(x => x.GetData()).Return(new []{1,2,3,4}).Repeat.Once();
Yet this does not cover the scenario where repeated enumerations of the result give different sets of values.
To give context I have a consumer method that calls the GetData method on the provider and uses the returned values twice, in error I enumerated the return twice, with unexpected behavior, but this was not highlighted in my unit tests on the consumer. As very simple consumer implementation to represent what I mean can be shown as:
class Consumer<T>
{
bool UseProvider(IIEnumerableProvider<T> provider)
{
var rangeIterator = provider.GetData();
var firstEnumeration = rangeIterator.ToArray();
var secondEnumeration = rangeIterator.ToArray();
return firstEnumeration.SequenceEquals(secondEnumeration);
}
}
you would expect this to return false if the provider returned a value that is different every time it is enumerated, which is the case if we have a simple concrete implementation of IIEnumerableProvider:
public class RandomIntIEnumerableProvider : IIEnumerableProvider<int>
{
private Random r = new Random();
public IEnumerable<int> GetData()
{
return Enumerable.Range(0,10).Select(x => r.Next());
}
}
So the question is how do I stub the provider in such a way as to produce well defined values on the first enumeration of the rangeIterator, but different (either defined as a list of sets of values or randomly determined). I need this in order to inject it into the consumer and ensure that the consumer is not performing multiple enumeration on the rangeIterator where it is a wrong to do so?
The naive approach of stubbing two return vales from the method does not work:
var stub = MockRepository.GenerateStub<IIEnumerableProvider<int>>();
stub.Stub(x => x.GetData()).Return(new []{1,2,3,4}).Repeat.Once();
stub.Stub(x => x.GetData()).Return(new []{5,6,7,8}).Repeat.Once();
as the GetData method is only called once, the set 1,2,3,4 is seen in the first and second enumerations.
Add another stub for the IEnumerable returned from GetData() and return that stub from the stub you described in the single enumeration approach in the question. With the first stub you can explicitly control the values that you return via WhenCalled().
var stubEnumerable = MockRepository.GenerateStub<IEnumerable<int>>();
stubEnumerable.Stub(x => x.GetEnumerator()).Return(null).WhenCalled(x => x.ReturnValue = ... );
var stub = MockRepository.GenerateStub<IIEnumerableProvider<int>>();
stub.Stub(x => x.GetData()).Return(stubEnumerable).Repeat.Once();
I'm a C# and Moq newb. I have some code that looks like the following and I want to unit test it, using Moq.
Data.Foo.FooDataTable tbl = Adapter.GetFooByID(id);
foreach (Data.Foo.FooRow row in tbl)
{
x = row.bar
...
}
How do I set up the mocks? Current broken attempt:
var adapter = new Mock<FooTableAdapter>();
var table = new Mock<Foo.FooDataTable>();
var rows = new Mock<DataRowCollection>();
var row = new Mock<Foo.FooRow>();
rows.Setup(x => x.GetEnumerator().Current).Returns(row.Object);
table.Setup(x => x.Rows).Returns(rows.Object);
adapter.Setup(x => x.GetFooByID(1)).Returns(table.Object);
_adapter = adapter.Object;
If I don't try to add the row, I get a NullReferenceException in the foreach. If I do try to add the row, I get a System.NotSupportedException: Type to mock must be an interface or an abstract or non-sealed class.
Mocks are awesome and all but they really are testing tools of last resort -- what you reach for when you've got some impossible to create object you can't avoid depending on -- such as HttpContext.
In this case, you probably don't want to create a moq mock of the DataTable -- you can just new up one with appropriate data. What you'd want to moq mock would be the call to Adapter.GetFooById() to spit back your test double of a data table.
Mocks should only be used to create fake dependencies when you want to test the behaviour of something that requires said dependency, but you don't want (or can't) actually create a "real" instance of that dependency. Any test method with more than a couple of mocks is headed in the wrong direction because it's a sign that you have either too many dependencies, or that you are testing too many unrelated things.
In the code you have above, there are no dependencies, so Mocks wouldn't be appropriate really what you need.
You really need to think about what exactly it is you are trying to test here. For the sake of argument let's assume that the code you showed is from a method:
public class MyFooClass
{
public int DoFooFooData(FooAdapter Foo)
{
Data.Foo.FooDataTable tbl = Adapter.GetFooByID(id);
//just imagining what you might do here.
int total=0;
foreach (Data.Foo.FooRow row in tbl)
{
x = row.bar
//just imagining what you might do here.
total+=x;
}
return total;
}
}
Now, let's further suppose that you want to unit test this method. In this case in order to call the method you have to supply a working FooAdapter instance because the method depends on it in order to work
But let's now say that you are not currently in possession of a FooAdapter because it doesn't exist, or maybe you can't supply one because FooAdapter makes a database connection which is a no-no in unit testing.
What we need to do in order to test DoFooFooData is to supply a fake (Mock) FooAdapter, which only implements the GetFooByID method, in order for your function to execute.
To do this you'll have to either make FooAdapter abstract or (I recommend) declare it by interface:
public interface IFooAdapter
{
Data.Foo.FooDataTable GetByID(int id);
}
(later on you'll need to change FooAdapter class to implement IFooAdapter if you want to actually use it with the DoFooFooData method for real)
Now change your method signature:
public void DoFooFooData(IFooAdapter Foo)
{
Data.Foo.FooDataTable tbl = Adapter.GetFooByID(id);
int total=0;
foreach (Data.Foo.FooRow row in tbl)
{
x = row.bar
//just imagining what you might do here
total+=x;
}
return total;
}
And finally in your test method, you can mock this dependency:
void DoFooFooData_DoesSomeFooAndReturns3()
{
var mock = new Mock<IFooAdapter>();
var table = new Data.Foo.FooDataTable();
table.Add(new Data.Foo.FowRow{bar=1});
table.Add(new Data.Foo.FowRow{bar=2});
mock.Setup(m=>m.GetByID(It.IsAny<int>()).Returns(table);
var sut = new MyFooClass();
var expected=3;
var actual=sut.DoFooFooData(mock.Object);
Assert.AreEqual(expected,actual);
}
Of course if you need to Mock FooDataTable as well you can follow the same pattern as you did with the IFooAdapter but you need to stop at this point and ask yourself if you shouldn't be creating a separate test in which you Mock an IFooDataTable and ensure that it does what it's supposed to do (Add method or whatever) and so on...at the point when you were sure that the behavioural contract of IFooDataTable is OK, you'd then implement it as a concrete "stub" which you can then use in place of any FooDataTable references in the context of an IFooAdapter...but now you're into integration tests which is a story for another day...
I've been looking at the Moq documentation and the comments are too short for me to understand each of things it can do.
The first thing I don't get is It.IsAny<string>(). //example using string
Is there an advantage of using this over just putting some value in? I know people say to use this if you don't care about the value, but if you don't care about the value can't you just do "a" or something? This just seems like more typing.
Secondly, when would be an example be of when you would not care about the value? I thought Moq needs the value to match up stuff.
I don't get what It.Is<> is for at all or how to use it. I don't understand the example and what it is trying to show.
Next, I don't get when to use Times (and its AtMost methods and similar). Why would you limit the number of times something is set up? I have some AppConfig value that I need to use twice. Why would I want to limit it to, say, once? This would just make the test fail. Is this to stop other people from adding another one to your code or something?
I don't get how to use mock.SetupAllProperties();
What does it set up the properties with?
I don't also get why there are so many different ways to set up a property and what their differences are. The documentation has:
SetupGet(of property)
SetupGet<TProperty>
I noticed that a lot of the stuff in Moq shows () and <> - what's the difference between them and what would they look like in use?
I also don't get why they have SetupGet. Would you not use SetupSet to set a property?
SetupSet has five different ways to use it in the documentation. Plus another one called SetupProperty. So I don't understand why there are so many.
On a side note, I am wondering if variables used in lambdas are independent of other lambdas. E.g.:
mock.setup(m => m.Test);
stop.setup(m => m.Test);
Would this be ok or would there be some conflict between the variable m?
Finally, I was watching this video and I am wondering if it shows Visual Studio. His Intellisense looks different. A lightbulb pops up for him (I am happy mine does not, as it brings back painful memories of netbeans), and there are lines going from one opening brace to the closing brace and etc.
It.IsAny / It.Is
These can be useful when you're passing a new reference type within the code under test. For instance, if you had a method along the lines of:
public void CreatePerson(string name, int age) {
Person person = new Person(name, age);
_personRepository.Add(person);
}
You might want to check the add method has been called on the repository,
[Test]
public void Create_Person_Calls_Add_On_Repository () {
Mock<IPersonRepository> mockRepository = new Mock<IPersonRepository>();
PersonManager manager = new PersonManager(mockRepository.Object);
manager.CreatePerson("Bob", 12);
mockRepository.Verify(p => p.Add(It.IsAny<Person>()));
}
If you wanted to make this test more explicit you can use It.Is by supplying a predicate the person object must match,
[Test]
public void Create_Person_Calls_Add_On_Repository () {
Mock<IPersonRepository> mockRepository = new Mock<IPersonRepository>();
PersonManager manager = new PersonManager(mockRepository.Object);
manager.CreatePerson("Bob", 12);
mockRepository.Verify(pr => pr.Add(It.Is<Person>(p => p.Age == 12)));
}
This way the test will through an exception if the person object that was used to call the add method didn't have the age property set to 12.
Times
If you had a method along the lines of:-
public void PayPensionContribution(Person person) {
if (person.Age > 65 || person.Age < 18) return;
//Do some complex logic
_pensionService.Pay(500M);
}
One of the things that you might want to test is that the pay method does not get called when a person aged over 65 is passed into the method
[Test]
public void Someone_over_65_does_not_pay_a_pension_contribution() {
Mock<IPensionService> mockPensionService = new Mock<IPensionService>();
Person p = new Person("test", 66);
PensionCalculator calc = new PensionCalculator(mockPensionService.Object);
calc.PayPensionContribution(p);
mockPensionService.Verify(ps => ps.Pay(It.IsAny<decimal>()), Times.Never());
}
Similarly, it's possible to imagine situations where you're iterating over a collection and calling a method for each item in the collection and you'd like to make sure that it's been called a certain amount of times, other times you simply don't care.
SetupGet / SetupSet
What you need to be aware of with these guys is that they reflect how your code is interacting with the mock rather than how you're setting up the mock
public static void SetAuditProperties(IAuditable auditable) {
auditable.ModifiedBy = Thread.CurrentPrincipal.Identity.Name;
}
In this case, the code is setting the ModifiedBy property of the IAuditable instance while it's getting the Name property of the current instance of IPrincipal,
[Test]
public void Accesses_Name_Of_Current_Principal_When_Setting_ModifiedBy() {
Mock<IPrincipal> mockPrincipal = new Mock<IPrincipal>();
Mock<IAuditable> mockAuditable = new Mock<IAuditable>();
mockPrincipal.SetupGet(p => p.Identity.Name).Returns("test");
Thread.CurrentPrincipal = mockPrincipal.Object;
AuditManager.SetAuditProperties(mockAuditable.Object);
mockPrincipal.VerifyGet(p => p.Identity.Name);
mockAuditable.VerifySet(a => a.ModifiedBy = "test");
}
In this case, we're setting up the name property on the mock of IPrincipal so it returns "test" when the getter is called on the Name property of Identity we're not setting the property itself.
SetupProperty / SetupAllProperties
Looking at the test above if it was changed to read
[Test]
public void Accesses_Name_Of_Current_Principal_When_Setting_ModifiedBy() {
Mock<IPrincipal> mockPrincipal = new Mock<IPrincipal>();
Mock<IAuditable> mockAuditable = new Mock<IAuditable>();
mockPrincipal.SetupGet(p => p.Identity.Name).Returns("test");
var auditable = mockAuditable.Object;
Thread.CurrentPrincipal = mockPrincipal.Object;
AuditManager.SetAuditProperties(auditable);
Assert.AreEqual("test", auditable.ModifiedBy);
}
The test would fail. This is because the proxy created by Moq doesn't actually do anything in the set method of a property unless you tell it to. In effect, the mock object looks a bit like this
public class AuditableMock : IAuditable {
public string ModifiedBy { get { return null; } set { } }
}
To get the test to pass you have to tell Moq to set up the property to have the standard property behavior. You can do this by calling SetupProperty and the mock will look more like
public class AuditableMock : IAuditable {
public string ModifiedBy { get; set; }
}
and the test above would pass as the value "test" would now get stored against the mock. When mocking complex objects you might want to do this for all properties, hence the SetupAllProperties shortcut
Finally, the lightbulb in the IDE is the ReSharper plugin.
If you don't care about the exact value of a property, it's far better to use .IsAny because you are being explicit about the fact that the exact value is not important. If you hardcode it as "abc", then it is not clear if your code you are testing depends on starting with "a" or ending with "c" or being 3 chars long, etc. etc.