The following constructor parameters did not have matching fixture data

Question

I'm trying to test my controllers using xUnit but getting the following error during execution of Customer Controller:

"The following constructor parameters did not have matching fixture data: CustomerController customerController"

Test Class

public class UnitTest1
{
    CustomerController _customerController;

    public UnitTest1(CustomerController customerController)
    {
        _customerController = customerController;
    }

    [Fact]
    public void PostTestSuccessful()
    {
        Guid guid = Guid.NewGuid();

        CustomerViewModel model = new CustomerViewModel()
        {
            Id = guid,
            Name = "testName",
            Email = "test email",
            PhoneNumber = "test phone",
            Address = "test address",
            City = "test city",
            Gender = "Male"
        };

        var actionResult = _customerController.Post(model);

        Assert.NotNull(actionResult);
        Assert.IsType<Task<IActionResult>>(actionResult);
        Assert.True(actionResult.IsCompletedSuccessfully);
    }

CustomerController Class

[Route("customers")]
public class CustomerController : ControllerBase
{
    private readonly ILogger _logger;
    private readonly ICustomerService _customerService;

    public CustomerController(ILogger<CustomerController> logger,
        ICustomerService customerService)
    {
        _logger = logger;
        _customerService = customerService;
    }

    [HttpPost]
    public async Task<IActionResult> Post([FromBody] CustomerViewModel viewModel)
    {
        var customerToBeSaved = viewModel.Adapt<CustomerServiceModel>();

        var customer = await _customerService.SaveAsync(customerToBeSaved);

        var result = customer.Adapt<CustomerViewModel>();

        return Ok(result);
    }

Solution 1

For the testing framework, you need the mocking library to inject a mock object through DI in your testing classes. You can use Nmock, Moq or any other mocking library to setup the constructor injection.

https://www.c-sharpcorner.com/uploadfile/john_charles/mocking-in-net-with-moq/

http://nmock.sourceforge.net/quickstart.html

Solution 2

What you are missing is the IClassFixture interface for the test class. This will fix the problem...

public class UnitTest1 : IClassFixture<CustomerController>

Solution 3

Just new up CustomerController in the constructor, if you don't want to use any mocking framework.

Solution 4

This article shows how to get xunit working with .Net Core ASP.Net really well. It actually replaces the startup so that your controllers run in the same process, and you can test them as if they were local.

https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests

It allows your standard .Net Dependency Injection to work as it normally does. Moreover it has the amazing benefit of not running as a server, and it fakes the whole startup process so that it runs in one single process and you can debug all the way through. This is also the way you should do it because Microsoft says so.

There's more help to be gleaned from the forum at the bottom of the article.

View more solutions

Comments

[DineshNS]

I am following the same link. Where should I configure DI for the factory ?

[Bluebaron]

I don't know in what context you're talking about. DI should be automagically enabled in .Net Core. Probably have to look at DI in .Net Core.

[DineshNS]

I am talking about Unit Test. But it is working now. Thank you

[DMur]

"new up CustomerController" ?

[Amicable]

@DMur they mean instantiate the controller in the class constructor e.g. _myPrivateProperty = new CustomerController();

[Matt]

A very complicated example for a simple issue. To be honest, I didn't understand how that helps here. Could you explain it?

[Bluebaron]

@Matt This allows your standard .Net Dependency Injection to work as it normally does. Moreover it has the amazing benefit of not running as a server. It fakes the whole startup process so that it runs in one single process and you can debug all the way through. This is also the way you should do it because Microsoft says so. There's more help to be gleaned from the forum at the bottom of the article. Thanks for the down vote.

[Bluebaron]

I should also mention this is the most correct answer here. Possibly even the only truly correct answer. Microsoft even says this is how it should be done. So before the upset, maybe take some time and put in the work.

[Matt]

Thank you for the explanations. Very helpful. Copy them into your answer and I promise I'll upvote it. Just providing a link is sometimes too short for an answer, especiallly if the linked article is quite long.

[Matt]

Doesn't it look better now? I edited and upvoted your answer, please be more descriptive in your future answers. Don't assume everyone knows what you know.

[Bluebaron]

Thanks. I might flesh it out a little more tomorrow.