Replies: 2 comments
-
The problem with your approach is the timing. When you let AutoFixture create the parameters for your test, this happens before the test method. So your approach using the fixture for your service is a chicken and egg problem. You cannot register anything AFTER the object is created and hope that your changes will happen magically. The AutoMoqDataAttribute you show, is the basic sample. While not using Moq but NSubstitute I usually have my own AutoDataAttribute with more functionality to provide support for further customization. I dont know what you really want to do, but just to make your example work you could re-write your test like this:
No need to interact on low level with the fixture instance. |
Beta Was this translation helpful? Give feedback.
-
Hi @MGrgov90, public class MyServiceCustomization : ICustomization
{
public void Customize(IFixture fixture)
{
fixture.Customizations.Insert(0, new TypeRelay(typeof(IService), typeof(Service1)));
}
} To use this customization you'll have to create a new attribute that will look like this. public class ServicesDataAttribute : AutoDataAttribute
{
public ServicesDataAttribute()
: base(() => new Fixture().Customize(
new CompositeCustomization(
new AutoMoqCustomization(),
new MyServiceCustomization())))
{
}
} Now when you'll resolve the service interface you should get the concrete implementation. [Theory]
[ServicesData]
public void Foo(IService service)
{
Assert.IsType<Service1>(service);
} |
Beta Was this translation helpful? Give feedback.
-
I need fixture instance created in AutoMoqDataAttribure to be used in unit tests.
So I can register concrete implementation of IService interface in my case Service1.
I know that instead of using concrete implementation I should probably mock it so the test for one class does not depends on another. Also there is a way to use it if I create IFixture instance in my unit test class.
The code sample is something what I interested in.
Beta Was this translation helpful? Give feedback.
All reactions