We Keep Coding

How can I arrange one property of my mock to set another property?

So I'm trying to mock an interface that contains a property that my unit test has to set initially, which is then altered by the subject under test, and then my assertion looks at the result.
The code under test looks like this:
public class Foo
{
IEnumerable<int> IntList { get; set; }
public void Bar(IBaz baz)
{
if (baz == null)
throw new ApplicationException();
if (baz.IntList == null)
baz.IntList = new List<int>();
this.IntList = baz.IntList;
}
}
I'm mocking my interface in a factory like this:
public class BazFactory
{
public IEnumerable<int> IntList { get; set; }
public IBaz Create()
{
IBaz baz = Mock.Create<IBaz>();
baz.Arrange(x => x.IntList).Returns(this.IntList);
return baz;
}
}
And my unit test consumes it all like this:
[Fact]
public void WithNullIntList_InitializesNew()
{
//Arrange
Foo foo = new Foo();
BazFactory factory = new BazFactory();
IBaz baz = factory.Create();
//Act
foo.Bar(baz);
//Assert
Assert.NotNull(foo.IntList);
}
Obviously, this isn't working, because though foo.Bar() tries to change baz.IntList, it still returns factory.IntList, which hasn't changed.
What I need is to be able to arrange baz.IntList so that when it is set, the value passed to it is diverted to factory.IntList instead. I have only seen documentation on how to do this with a variable inside the mock class, and how to do it with a method, but not with a property's setter.
I feel like I should be able to add a line to BazFactory.Create() like this, but the following code doesn't work.
baz.ArrangeSet(x => this.IntList = x.IntList);
How can I express "the value passed to baz.IntList" in the context of an action?
If it makes a difference, I am using the Lite version of JustMock.

Mock method return value with read only property

I wish to test a method which queries a third-party library. The library returns an object with a IReadOnlyCollection property.
There is no constructor to set the value of the property and the object has no interface for me to mock.
I have used Moq to mock the interface for the service that I call, but I can't create a mocked return value as I can't set the property.
public interface IHitService {
public Hit GetHit();
}
public class Hit {
public Hit() {
}
public IReadOnlyCollection<string> Result { get; }
}
public class TestingClass {
public void MyTest() {
Hit hit = new Hit() {
// cannot set this property
Result = new List<string>() { "hello","goodbye" };
}
Mock<IHitService> service = new Mock<IHitService>();
service.Setup(c => c.GetHit).Returns(hit);
}
}
What would be the best way for me to generate the return value to test my method? Wrapping the object with a new property to hide the base does not work.

You can use unit-test frameworks that allow you to change the behavior of a concrete object, for example in this case i used Typemock Isolator to try and solve your issue, it allows you to change the the return value of the result property so can "set" for your test without changing your code or adding extra code:
public void TestMethod1()
{
List<string> s = new List<string> { "sfas", "asfsa", "blbba" };
var hit = Isolate.Fake.NextInstance<Hit>();
Isolate.WhenCalled(() => hit.Result).WillReturnCollectionValuesOf(s);
}
In this test i mocked the Hit class and modified the return value of the Result property to a list of strings i created.

If you need to test a third-party library, it would be a better idea to create your own abstraction (interface) and rely on that for both testing and real code:
public interface IHitService
{
IHit GetHit();
}
public interface IHit
{
IReadOnlyCollection<string> Result { get; }
}
In your application code, you can create a simple wrapper class that implements IHit by delegating to the concrete third-party class. Now you can test the interface by mocking it as needed.

In general, if you can't change 3rd party code, build an adapter to it and use your own abstraction :-
public interface IHit
{
IReadOnlyCollection<string> Result { get; }
}
public interface IHitService
{
IHit GetHit();
}
public class HitAdapter : IHit
{
private Hit _hit;
public HitAdapter(Hit hit)
{
_hit = hit;
}
public IReadOnlyCollection<string> Result => _hit.Result;
}
public class TestingClass
{
public void MyTest()
{
var hitMock = new Mock<IHit>();
hitMock.Setup(c => c.Result).Returns<IReadOnlyCollection<string>>(x => new List<string>() {"hello", "goodbye"});
var service = new Mock<IHitService>();
service.Setup(c => c.GetHit()).Returns<IHit>(x => hitMock.Object);
}
}

Unit Test Null Parameters in Constructor

I have coded a constructor for a class and I am testing for each parameter being null. See example below:
public MyClass(IObjectA objA, IObjectB objB) : IMyClass
{
if (objA == null)
{
throw new ArgumentNullException("objA");
}
if (objB == null)
{
throw new ArgumentNullException("objB");
}
...
}
Usually I unit test (using Moq) this by mocking out IObjectA and IObjectB and passing them in. The example above would create 2 unit tests to test each scenario.
The problem I have is when a 3rd parameter is passed into the constructor. It requires that I alter my previous tests, as I suddenly get a "No constructor for MyClass has 2 parameters" type exception.
I also use AutoMockContainer. Essentially I'd like to be able to test the constructor by registering a null object in the container. For example:
[TestMethod]
[ExpectedException(typeof(ArgumentNullException))]
public void ConstructionThrowsExceptionForNullObjA()
{
// Arrange.
var container = new AutoMockContainer(new MockRepository(MockBehavior.Default));
container.Register<IObjectA>(null);
// Act.
var sut = container.Create<MyClass>();
}
Then it doesn't matter how many new parameters are added to the constructor. I will not have to update my unit tests.
Sadly, the above unit test passes. But for the wrong reason. The Register<T>() method throws the ArgumentNullException not the code executed in the 'Act' section.
Does anyone have a suggestion for being able to test constructor parameters and not have to revisit the unit test when new parameters are later added?

You can help alleviate some of this burden by utilizing either the factory or builder patterns to create your objects.
A simplified example of the builder pattern would be:
public class Foo
{
public string Prop1 { get; private set; }
public Foo(string prop1)
{
this.Prop1 = prop1;
}
}
[TestClass]
public class FooTests
{
[TestMethod]
public void SomeTestThatRequiresAFoo()
{
Foo f = new Foo("a");
// testy stuff
}
[TestMethod]
public void SomeTestThatRequiresAFooUtilizingBuilderPattern()
{
Foo f = new FooBuilder().Build();
}
[TestMethod]
public void SomeTestThatRequiresAFooUtilizingBuilderPatternOverrideDefaultValue()
{
Foo f = new FooBuilder()
.WithProp1("different than default")
.Build();
}
}
internal class FooBuilder
{
public string Prop1 { get; private set; }
// default constructor, provide default values to Foo object
public FooBuilder()
{
this.Prop1 = "test";
}
// Sets the "Prop1" value and returns this, done this way to create a "Fluent API"
public FooBuilder WithProp1(string prop1)
{
this.Prop1 = prop1;
return this;
}
// Builds the Foo object by utilizing the properties created as BuilderConstruction and/or the "With[PropName]" methods.
public Foo Build()
{
return new Foo(
this.Prop1
);
}
}
This way if/when your Foo object changes, it's a bit easier to update your unit tests to take the changes into account.
Consider:
public class Foo
{
public string Prop1 { get; private set; }
public string Prop2 { get; private set; }
public Foo(string prop1, string prop2)
{
this.Prop1 = prop1;
this.Prop2 = prop2
}
}
With this implementation your unit tests will break, but updating your builder is much easier than updating each unit test relying on the proper construction of a Foo
internal class FooBuilder
{
public string Prop1 { get; private set; }
public string Prop2 { get; private set; }
// default constructor, provide default values to Foo object
public FooBuilder()
{
this.Prop1 = "test";
this.Prop2 = "another value";
}
// Sets the "Prop1" value and returns this, done this way to create a "Fluent API"
public FooBuilder WithProp1(string prop1)
{
this.Prop1 = prop1;
return this;
}
// Similar to the "WithProp1"
public FooBuilder WithProp2(string prop2)
{
this.Prop2 = prop2;
return this;
}
// Builds the Foo object by utilizing the properties created as BuilderConstruction and/or the "With[PropName]" methods.
public Foo Build()
{
return new Foo(
this.Prop1,
this.Prop2
);
}
}
With this new implementation of Foo and FooBuilder, the only unit test that would break is the one that created the Foo manually, the FooBuilder utilizing unit tests will still work without error.
This is a simplified example, but imagine if you had 20-30 unit tests reliant on the construction of a Foo object. Rather than updating those 20-30 unit tests, you can simply just update your builder to properly construct the Foo object.
In your example to unit test a null in the constructor, you could write the unit test using the builder pattern as such:
[TestMethod]
public void TestWithNullInFirstParam()
{
Foo f = new FooBuilder()
.WithProp1(null)
.Build()
// in this case "f" will have Prop1 = null, prop2 = "another value"
}

Stub a readonly property in a baseclass

I have a class like this:
public class Customer : CustomerBase
{
// internals are visible to test
internal string GenString()
{
// this actually composes a number of different properties
// from the parent, child and system properties
return this.InfoProperty.Name + DateTime.Now.ToString() + "something else";
}
}
// this class is in a 3rd party library, but from metadata it looks like this
public class CustomerBase
{
public Info InfoProperty { get; }
}
My test looks something like this:
public class Tests
{
public void MyTest()
{
using (ShimsContext.Create())
{
// Arrange
/* I shim datetime etc. static calls */
Fakes.StubCustomer c = new Fakes.StubCustomer()
{
InfoProperty = new Info("Name") // <- Error here because it's readonly
};
// Act
string result = c.GenString();
// Assert
Assert.AreEqual(result, "whatnot");
}
}
}
So my question is, how can I stub/shim the readonly property so that I can test this function?

What about wrapping this getter in an ad hoc virtual method that could be overrided by a mock?
Eg:
public class Customer : CustomerBase
{
// internals are visible to test
internal string GenString()
{
// this actually composes a number of different properties
// from the parent, child and system properties
return InfoPropertyNameGetter() + DateTime.Now.ToString() + "something else";
}
public virtual string InfoPropertyNameGetter(){
retrn this.InfoProperty.Name;
}
}
Mock<Customer> mock = new Mock<Customer>();
mock.Setup(m => m.InfoPropertyNameGetter()).Returns("My custom value");
It would look a bit like the Introduce Instance Delegator pattern described in Working effectively with legacy code

MEF Constructor Parameters with Multiple Constructors

I'm starting to use MEF, and I have a class with multiple constructors, like this:
[Export(typeof(ifoo))]
class foo : ifoo {
void foo() { ... }
[ImportingConstructor]
void foo(object par1) { ... }
}
I am using catalog.ComposeExportedValue() when composing to supply the par1
value to second constructor:
...
catalog.ComposeExportedValue(par1Value);
catalog.ComposeParts(this);
...
To hold the components I'm using:
[ImportMany(typeof(ifoo))]
public List<Lazy<ifoo, ifoometadata>> FooList { get; set; }
And to create the foo instance I'm using the value property, FooList[0].Value.
Everthing works fine, except that the second constructor of the foo class is never called. What's wrong?
How do I select the constructor I want to use when MEF instantiates the class?

MEF should use the constructor you put the ImportingConstructorAttribute on. I'm not sure what is happening for you, I wasn't able to reproduce the issue. Here is a test which shows using an ImportingConstructor on a class that also has a default constructor:
[TestClass]
public class MefTest
{
public const string ConstructorParameterContract = "FooConstructorParameterContract";
[TestMethod]
public void TestConstructorInjectionWithMultipleConstructors()
{
string ExpectedConstructorParameterValue = "42";
var catalog = new TypeCatalog(typeof(Foo), typeof(FooImporter));
var container = new CompositionContainer(catalog);
container.ComposeExportedValue<string>(ConstructorParameterContract, ExpectedConstructorParameterValue);
var fooImporter = container.GetExportedValue<FooImporter>();
Assert.AreEqual(1, fooImporter.FooList.Count, "Expect a single IFoo import in the list");
Assert.AreEqual(ExpectedConstructorParameterValue, fooImporter.FooList[0].Value.ConstructorParameter, "Expected foo's ConstructorParameter to have the correct value.");
}
}
public interface IFoo
{
string ConstructorParameter { get; }
}
[Export(typeof(IFoo))]
public class Foo : IFoo
{
public Foo()
{
ConstructorParameter = null;
}
[ImportingConstructor]
public Foo([Import(MefTest.ConstructorParameterContract)]string constructorParameter)
{
this.ConstructorParameter = constructorParameter;
}
public string ConstructorParameter { get; private set; }
}
[Export]
public class FooImporter
{
[ImportMany]
public List<Lazy<IFoo>> FooList { get; set; }
}

Are you passing an instance of the foo class into the ComposeExportedValue method? In that case the object has already been constructed and the constructor can't be called again, so MEF will ignore the constructor imports.