Я пытаюсь выполнить тестирование своих контроллеров API с помощью MSTest. Я следую приведенному здесь учебному пособию: https://www.asp.net/web-api/overview/testing-and-debugging/mocking-entity-framework-when-unit-testing-aspnet-web-api-2Как проверить API-контроллер с функциями async?
В этом учебном пособии, к сожалению, не рассматриваются какие ухищрения, чтобы заставить его работать для асинхронных функций в контроллере.
В приведенном ниже коде тест проходит успешно, если я запускаю его на неконтролируемом контроллере. Но когда я тестирую его на async-функции, это дает мне ошибку.
public async Task GetService_ShouldReturnCorrectServiceId()
{
//Arrange
var context = new TestContext();
context.Services.Add(new Service { Service_ID = 1, Service_Name = "WEBAPPS"});
//Act
var controller = new ServicesController(context);
var result = await controller.GetServiceId("WEBAPPS") as OkNegotiatedContentResult<Service>;
//Assert
Assert.IsNotNull(result);
Assert.AreEqual(1, result.Content.Service_ID);
}
Тест терпит неудачу дает эту ошибку:
the provider for the source iqueryable doesn't implement idbasyncqueryprovider
Мой метод управления является:
public async Task<IHttpActionResult> GetServiceId(string name)
{
var service_id = await db.Services
.Where(s => (s.Service_Name == name))
.FirstOrDefaultAsync();
if (service_id == null)
{
return NotFound();
}
return Ok(service_id);
}
И файл TestContext является:
class TestContext : IContext
{
public TestContext()
{
this.Services = new TestServiceDbSet();
}
public DbSet<Service> Services { get; set; }
public void Dispose() { }
}
И я следовал все шаги к письму в этой ссылке abov е. Я думаю, что код TestDbSet (см. Эту ссылку) должен быть обновлен для учета асинхронных методов, но я не уверен, как это сделать.
Цените любую помощь! Благодарю.
Его реализация типа 'TestServiceDbSet'. Есть два возможных способа сделать это, и первый способ не будет работать с кодом 'async', только второй будет. К сожалению, приведенный вами пример не упоминает об этом. См. [Тестирование с помощью собственных тестовых удвоений] (https://msdn.microsoft.com/en-us/data/dn314431.aspx). Я написал несколько расширений вокруг этого, чтобы упростить повторное использование во всем тестовом проекте, см. [DbContext Data Mocking для модульного тестирования] (https://github.com/IgorWolbers/DbContextMockForUnitTests) – Igor
@Igor Спасибо! Посмотрите. Есть ли более простой способ проверить это с помощью moq/nunit? – 90abyss
Испытательный жгут не имеет большого значения. Что касается создания подделок, я предпочитаю NSubstitute (доступный через NuGet), но я не думаю, что это слишком важно, его более личные предпочтения. Ваш дизайн, хотя и оказывает наибольшее влияние на способность тестировать. Сохранение ваших типов ссылок внутри вашего контроллера как можно более абстрактным/общим - это лучший способ обеспечить легкое тестирование. При использовании EF я использую ссылочный тип DbContext и никогда не производные типы и не использую Set(), чтобы получить DbSets , тогда его легко вводить поддельный DbContext с издеваемым набором в контроллере или службе. –
Igor