I've been using AutoFixture / AutoMoqData / Nunit for several months now, quite happily so far.
But I'm getting stuck on something weird:
If I want to run a single test in a test suite (using TestDriven), it seems that the AutoMoqData attribute is launched several times (between 5 and 9, but I don't really know why, and what decides how many times it runs).
The problem is that if I try to freeze an object instance in AutoFixture customizations, it'll end up freezing 5 to 9 objects, using this many fixture instances, and will have no clue which one is injected in my test.
Is there a way to avoid this ? Why does it happen in the first place ?
Sample code :
public class AutoMoqDataAttribute : AutoDataAttribute
{
public AutoMoqDataAttribute()
: base(new Fixture()
.Customize(new AutoMoqCustomization())
.Customize(new FrozenFooCustomization()) // freezing an object
.Customize(new FrozenFixtureCustomization()) // freezing the passed fixture to have the fixture instance available in the test body
.Customize(new StaticBindingCustomization()) // binding the frozen object to a static reference
)
{
}
}
public class FrozenFooCustomization : ICustomization
{
public void Customize(IFixture fixture)
{
fixture.Freeze<Foo>();
}
}
public class Foo { }
public class FrozenFixtureCustomization : ICustomization
{
public void Customize(IFixture fixture)
{
fixture.Inject(fixture);
}
}
public class StaticBindingCustomization : ICustomization
{
public void Customize(IFixture fixture)
{
fixture.Freeze<Mock<ISomeUtilities>>();
var someUtilities = fixture.Create<Mock<ISomeUtilities>>();
someUtilities.Setup(x => x.GetStuff()).Returns(fixture.Create<Foo>());
// this is executed several times, each time with a different instance of fixture, returning a different instance of Foo
SomeExtensions.Factory = x => someUtilities.Object;
// so the last "someUtilities.Object" is bound to the factory, but the test relies on a frozen version generated by one of the previous fixture instances
}
}
[TestFixture]
public class Test
{
[Test, AutoMoqData]
public void SomeTest(
[Frozen]Mock<ISomeUtilities> objMock,
SomeObjectToTest sut)
{
Assert.IsTrue(ReferenceEquals(objMock.Object.GetStuff(), sut.GetStuff()));
}
}
public class SomeObjectToTest { }
public static class SomeExtensions
{
public static Func<object, ISomeUtilities> Factory { get; set; } = x => new SomeUtilities(x);
public static object GetStuff(this object obj)
{
return Factory(obj).GetStuff();
}
}
public class SomeUtilities : ISomeUtilities
{
private readonly object _obj;
public SomeUtilities(object obj)
{
_obj = obj;
}
public object GetStuff()
{
return _obj; // whatever
}
}
public interface ISomeUtilities
{
object GetStuff();
}
EDIT: SomeExtensions.Factory is a factory used to make extensions mockable, based on Daniel Cazzulino's approach.
I'm not a big fan of those extensions and hope to refactor them at some point, but this is for another time. The question here is why are there several fixture instances, making the frozen SomeUtilities mock used in the factory different than the one used in the test, and thus the test to fail.
EDIT2: Following #MarkSeemann's advice, I reported an issue on Autofixture repo.
Related
I want to do something like this to provide methods from test classes to other test classes using composition.
public class SomeTestClass : IClassFixture<SomeService>
{
private readonly SomeService SomeService;
public SomeTestClass(SomeService someService)
{
SomeService = someService;
}
[Fact]
private void Test()
{
//....
}
public SomeData CreateSomeData()
{
// populate fields with something based on internal/service state
return new SomeData();
}
public void DoSomeAction(....)
{
// does action which modifies internal/service state
}
}
public class SomeConsumingClass : IClassFixture<SomeTestClass>
{
private readonly SomeTestClass SomeTestClass;
public SomeConsumingClass(SomeTestClass someTestClass)
{
SomeTestClass = someTestClass;
}
[Fact]
private void Test()
{
var data = SomeTestClass.CreateSomeData();
// ....
SomeTestClass.DoSomeAction(...)
}
}
The test in SomeTestClass passes but the test in SomeConsumingClass fails with a message
Class fixture type 'Requirements.SomeTestClass' had one or more unresolved constructor arguments: SomeService someService) (The following constructor parameters did not have matching fixture data: SomeTestClass someTestClass
It seems like a feature like this is not directly supported as it seems to be looking for a parameterless constructor. I intended to use this pattern for each test class, therefore I am looking for some good way to do something similar without too much boilerplate code. Any suggestions on how I could provide methods from the other test classes without inheritance?
EDIT:
Added some additional examples how I imagine myself using this
From the xUnit documentation on Class Fixtures (emphasis added):
Note that you cannot control the order that fixture objects are created, and fixtures cannot take dependencies on other fixtures. If you have need to control creation order and/or have dependencies between fixtures, you should create a class which encapsulates the other two fixtures, so that it can do the object creation itself.
One solution would be to move the CreateSomeData method to SomeService, and then change SomeConsumingClass so that it also implements IClassFixture<SomeService>.
However, it's worth pointing out this line from the documentation regarding when IClassFixture is appropriate:
When to use: when you want to create a single test context and share it among all the tests in the class, and have it cleaned up after all the tests in the class have finished.
From the description you've provided, it doesn't seem clear to me that IClassFixture is necessary here, since all you really want is the ability to call CreateSomeData from different test classes. A dead-simple alternative would be to just move GetSomeData to a utility class that can be directly called from any test fixture that needs it.
So I played around with possible solutions and was able to come up with a solution which allows for identical behavior
public class SomeTestClass
{
private readonly SomeService SomeService;
public SomeTestClass(SomeService someService)
{
SomeService = someService;
}
[Fact]
private void Test()
{
//....
}
public SomeData CreateSomeData()
{
// populate fields with something based on internal/service state
return new SomeData();
}
public void DoSomeAction(....)
{
// does action which modifies internal/service state
}
}
public class SomeDerivingTestClass : SomeTestClass
{
public SomeDerivingTestClass() : base(CreateSomeService())
{
}
private static SomeService CreateSomeService()
{
return new SomeService();
}
}
public class SomeConsumingClass : IClassFixture<SomeDerivingTestClass>
{
private readonly SomeTestClass SomeTestClass;
public SomeConsumingClass(SomeDerivingTestClass someTestClass)
{
SomeTestClass = someTestClass;
}
[Fact]
private void Test()
{
var data = SomeTestClass.CreateSomeData();
// ....
SomeTestClass.DoSomeAction(...)
}
}
We are building an application where we have to have both old and new version to work side by side (V1 is old and V2 is new). Now to handle new flow we are using same old interfaces with everything being the same and differs only in functionality, hence now we have to define a named instance in-order to resolve the instances for new flow.
In the process teams have started using Service Factory Pattern as shown below
class DataProcessor
{
private readonly IDataManager _dataManager;
public DataProcessor(IServiceFactory serviceFactory)
{
_dataManager = serviceFactory.GetInstance<IDataManager>();
}
public void Execute()
{
_dataManager.Run();
}
}
Service Factory Class
public class ServiceFactory : IServiceFactory
{
private readonly IFeatureEvaluator _featureEvaluator;
public ServiceFactory(IFeatureEvaluator featureEvaluator)
{
_featureEvaluator = featureEvaluator;
}
public T GetInstance<T>()
{
if (_featureEvaluator.IsEnabled<"V2">())
{
return ObjectFactory.GetInstance<T>("V2")
}
return ObjectFactory.GetInstance<T>();
}
}
Since Service Factory is anti-pattern and also it creates lot of complexities in retiring the old flow in future, I would want a way to initialize the dependencies at the container(structuremap ioc) itself or to work in a "Pure DI" way so that we can avoid headache. Any idea on how to tackle this.
Update:
IDataManager Implementation
public interface IDataManager
{
void Run();
}
public class OldFlow : IDataManager
{
public void Run()
{
//
}
}
public class NewFlow : IDataManager
{
public void Run()
{
//
}
}
IDataManager has 2 implementations and resolving the instance should be based on _featureEvaluator, if V2 flow then "newflow" should be instantiated else "old flow" instance
Why don't you just inject the dependency you need?
public class DataProcessor
{
private readonly IDataManager _dataManager;
public DataProcessor(IDataManager dataManager)
{
_dataManager = dataManager;
}
public void Execute()
{
_dataManager.Run();
}
}
In your Composition Root you can conditionally compose DataProcessor with the implementation of IDataManager you'd like:
public DataProcessor CreateDataProcessor()
{
if (_featureEvaluator.IsEnabled<"V2">())
{
IDataManager dm = new NewFlow();
return new DataProcessor(dm);
}
IDataManager dm = new OldFlow();
return new DataProcessor(dm);
}
This seems to be similar to feature toggles. Why, by the way, is _featureEvaluator an interface? Wouldn't a bool suffice?
I am using AutoFixture to mock an external library that doesn't always implement interfaces, but has a default ctor without parameters.
Currently, I am using Moq/AutoMoq framework like that:
mocker.GetMock<HeavyDependency>()
.Setup(x => x.GetData())
.Returns("TEST DATA");
I want to have the same behaviour with AutoFixture.AutoMoq. My code:
namespace AutoFixtureNUnit.TestsCs
{
public class HeavyDependency1
{
public HeavyDependency1() => Debug.WriteLine("HeavyDependency1");
}
public class HeavyDependency2
{
public HeavyDependency2() => Debug.WriteLine("HeavyDependency2");
}
public class MyClassWithHeavyDependency
{
private readonly HeavyDependency1 dep1;
private readonly HeavyDependency2 dep2;
public MyClassWithHeavyDependency() => Debug.WriteLine("MyClassWithHeavyDependency default.");
public MyClassWithHeavyDependency(HeavyDependency1 h1, HeavyDependency2 h2)
{
Debug.WriteLine("MyClassWithHeavyDependency injected.");
dep1 = h1;
dep2 = h2;
}
}
[TestFixture]
public class TestClass
{
private Fixture _fixture;
private Mock<HeavyDependency1> _heavyMock;
MyClassWithHeavyDependency _sut;
[SetUp]
public void SetUp()
{
_fixture = new Fixture();
_fixture
.Customize(new ConstructorCustomization(typeof(MyClassWithHeavyDependency), new GreedyConstructorQuery()))
.Customize(new AutoMoqCustomization(){ConfigureMembers = false});
_heavyMock = new Mock<HeavyDependency1>();
_fixture.Inject(_heavyMock.Object);
_sut = _fixture.Create<MyClassWithHeavyDependency>();
}
[Test]
public void TestMethod()
{
Assert.Pass("Your first passing test");
}
}
}
MyClassWithHeavyDependency has a ctor that takes dependent objects and code above calls that ctor.
So far so good. I am injecting the Mock of the dependent object and verifying calls.
The problem:
For the mocks that are Injected, the constructor is called with the Mock like: {Mock<AutoFixtureNUnit.TestsCs.HeavyDependency1:00000001>.Object}.
However, for all other types it is called with the parameter of {AutoFixtureNUnit.TestsCs.HeavyDependency2}. Which is not what I want and is not used by the current tests. Not a Moq object, right?
It is mocking my own interfaces as well.
Question:
Can I somehow specify that AutoFixture.AutoMoq should mock all ctor parameters that are not manually mocked by me?
Because Freezing/injecting every single one is not different from manual mock setup and requires a lot of code changes every time I add ctor parameter.
Actually, I can see HeavyDependency1 ctor called as well. Seems strange.
I have a base class for my tests which is composed in the following way:
[TestClass]
public abstract class MyBaseTest
{
protected static string myField = "";
[ClassInitialize]
public static void ClassInitialize(TestContext context)
{
// static field initialization
myField = "new value";
}
}
Now I am trying to create a new test that inherits from the base, with the following signature:
[TestClass]
public class MyTest : MyBaseTest
{
[TestMethod]
public void BaseMethod_ShouldHave_FieldInitialized()
{
Assert.IsTrue(myField == "new value");
}
}
The ClassInitialize is never called by the child tests ... What is the real and correct way of using test initialization with inheritance on MsTest?
Unfortunately you cannot achieve this that way because the ClassInitializeAttribute Class cannot be inherited.
An inherited attribute can be used by the sub-classes of the classes that use it. Since the ClassInitializeAttribute cannot not be inherited, when the MyTest class is initialized the ClassInitialize method from the MyBaseTest class cannot be called.
Try to solve it with another way. A less efficient way is to define again the ClassInitialize method in MyTest and just call the base method instead of duplicating the code.
A potential workaround is to define a new class with AssemblyInitializeAttribute instead. It has a different scope, obviously, but for me it meets my needs (cross-cutting concerns, which just so happen to require exactly the same settings for every test class and test method.)
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace MyTests
{
[TestClass]
public sealed class TestAssemblyInitialize
{
[AssemblyInitialize]
public static void Initialize(TestContext context)
{
...
}
}
}
Use a static constructor on a base class? It's executed only once, by design, and it doesn't have the weird limitation on inheritance, like the ClassInitializeAttribute.
There is a parameter for the ClassInitialize and ClassCleanup attributes:
[ClassInitialize(InheritanceBehavior.BeforeEachDerivedClass)]
public static void ClassInitialize(TestContext context)
{
// gets called once for each class derived from this class
// on initialization
}
[ClassCleanup(InheritanceBehavior.BeforeEachDerivedClass)]
public static void Cleanup()
{
// gets called once for each class derived from this class
// on cleanup
}
which will actually do what you want.
UPDATE: Added lock to avoid multi-threading issues...
We know that a new instance of the class is constructed for every [TestMethod] in the class as it gets run. The parameter-less constructor of the base class will be called each time this happens. Couldn't you simply create a static variable in the base class and test it when constructor runs?
This helps you to not forget to put the initialization code in the sub-class.
Not sure if there's any drawback to this approach...
Like so:
public class TestBase
{
private static bool _isInitialized = false;
private object _locker = new object();
public TestBase()
{
lock (_locker)
{
if (!_isInitialized)
{
TestClassInitialize();
_isInitialized = true;
}
}
}
public void TestClassInitialize()
{
// Do one-time init stuff
}
}
public class SalesOrderTotals_Test : TestBase
{
[TestMethod]
public void TotalsCalulateWhenThereIsNoSalesTax()
{
}
[TestMethod]
public void TotalsCalulateWhenThereIsSalesTax()
{
}
}
How can I test the IsHappy function using Moles?
class SomeClass
{
protected virtual bool IsHappy(string mood)
{
return (mood == "Happy");
}
}
I tried to test if by using Stub:
SSomeClass stub = new SSomeClass();
stub.CallBase = true;
Assert.IsTrue(stub.IsHappyString("Happy"));
... but the IsHappyString method returns null thus throwing a NullReference exception.
So, how can I test the default implementation of IsHappy method?
I'd forget about stubs here. Stubs/mocks are for when you want to fake the behavior of a dependency. You'd stub your SomeClass if had SomeClassClient that you wanted to test and it used SomeClass:
public class Foo
{
public virtual int GetFoosInt()
{
return 12;
}
}
public class FooClient
{
private Foo _foo;
public FooClient(Foo foo)
{
_foo = foo;
}
public int AddOneToFoosInt()
{
return _foo.GetFoosInt() + 1;
}
}
In this example, when testing FooClient, what you want to test is that it returns one more than "GetFoosInt()". You don't actually care what FoosInt is for testing the FooClient. So, you create a Foo stub where you can setup GetFoosInt to return whatever you want.
In your case, testing a protected virtual member, I'd go with this:
[TestClass]
public class SomeClassTest
{
private class DummySomeClass : SomeClass
{
public bool IsHappyWrapper(string mood)
{
return IsHappy(mood);
}
}
[TestMethod]
public void SomeTest()
{
var myClass = new DummySomeClass();
Assert.IsTrue(myClass.IsHappyWrapper("Happy"));
}
}
This gives you 'direct' access to the protected virtual to test default behavior. Only word of caution is that if you start defining abstract members and adding to SomeClass in general, you'll have to add them to this dummy inheritor as well, adding to testing maintenance overhead.
The purist in me says that you should leave protected members alone and only test them through the public interface. But, that may or may not be practical in your situation, and I don't really see any harm in this approach.
Stubs and Moles are for isolating a class from any dependencies it has, either environmental dependencies or class dependencies. This class has no dependencies whatsoever, so why are you trying to mole or stub it?
If you want to make sure this base class works properly when people override it, then you'll need to create a test implementation. In that case this is more or less what your test cases should look like:
public SomeClassTestAdapter : SomeClass
{
public bool GetIsHappy(string mood)
{
return IsHappy(mood);
}
}
[Test]
public void ShouldReturnTrueWhenPassedHappy()
{
var classUnderTest = new SomeClassTestAdapter();
bool result = classUnderTest.IsHappy("Happy");
Assert.IsTrue(result, "Expected result to be true");
}
[Test]
public void ShouldReturnFalseWhenPassedLowerCaseHappy()
{
var classUnderTest = new SomeClassTestAdapter();
bool result = classUnderTest.IsHappy("happy");
Assert.IsFalse(result, "Expected result to be false");
}
[Test]
public void ShouldReturnFalseWhenPassedNull()
{
var classUnderTest = new SomeClassTestAdapter();
bool result = classUnderTest.IsHappy(null);
Assert.IsFalse(result, "Expected result to be false");
}
Etc.
There is no place in this code that stubs or moles should be squeezed in.
If you don't want to create an adapter class for this case, you can use built-in .Net features rather than a big, paid dependency like Moles. Reflections and dynamic let you get access to protected or private members. See this example:
http://igoro.com/archive/use-c-dynamic-typing-to-conveniently-access-internals-of-an-object/