Reputation: 15270
I'm having an issue where AutoFixture seems to be overwriting a property on a frozen mock. The property on the mocked class is read-only, and from what I've read, AutoFixture shouldn't be trying to do anything with it.
I've included code to reproduce the issue in LINQPad below. Victim
is a trivial test class with two read-only properties. At issue is that once I have set the expectation for the Things
property and registered the mock's Object
as the instance for AutoFixture to return for the Victim
type, the collection Things
contains different strings.
To reproduce the problem, run the code below in LINQPad as a C# Program and reference AutoFixture and Moq from NuGet. Be sure to include the namespaces Moq and Ploeh.AutoFixture.
My expectation is that I should get back the object I registered with Register
and that the collection Things
in the returned Victim
should return the collection I referenced in my call to SetupGet
.
public class Victim
{
private string _vic;
private IEnumerable<string> _things;
public virtual string VictimName { get { return _vic; } }
public virtual IEnumerable<string> Things { get { return _things; } }
}
void Main()
{
var fixture = new Fixture();
var victimName = fixture.CreateAnonymous("VIC_");
var things = fixture.CreateMany<string>();
victimName.Dump("Generated vic name");
things.Dump("Generated things");
var victimMock = fixture.Freeze<Mock<Victim>>();
victimMock.SetupGet(x => x.VictimName).Returns(victimName).Verifiable();
victimMock.SetupGet(x => x.Things).Returns(things).Verifiable();
fixture.Register(() => victimMock.Object);
var victim = fixture.CreateAnonymous<Victim>();
(victim.Equals(victimMock.Object)).Dump("Victims are the same?");
victim.VictimName.Dump("Returned name");
victim.Things.Dump("Returned things");
(things.Equals(victim.Things)).Dump("Returned things are the same?");
victimMock.Verify();
}
Upvotes: 3
Views: 522
Reputation: 233125
My guess is that the Iterator for Things
is actually the same, but that the strings it generates are different. This is actually by design, although we've later come to realize that this wasn't a particularly good design decision.
In AutoFixture 3, this behavior has been changed.
If I've guessed correctly, this issue will go away in AutoFixture 3. In AutoFixture 2 you should be able to resolve it by creating the fixture like this:
var fixture = new Fixture().Customize(new StableMultipeCustomization());
Upvotes: 4