Маршруты в AspNetCore.TestHost зависят от местоположения Startup.cs?
Я пытаюсь протестировать основное веб-приложение ASP.NET с помощью Microsoft.AspNetCore.TestHost. Так работает нормально (результат имеет статус 200):
var server = new TestServer(new WebHostBuilder().UseStartup<Startup>());
var client = server.CreateClient();
var result = await client.GetAsync(someRequestUrl);
В этом случае используется настоящий класс Startup из проекта API.
Однако я не хочу использовать настоящий класс Startup в своем интеграционном тесте. Основной причиной является необходимость издеваться над некоторыми вещами, которые подключаются во время запуска приложения. Например, сервер базы данных, который будет использоваться. Это можно сделать очень элегантным способом, определив виртуальный метод в Startup.cs:
public virtual void SetupDbContext(IServiceCollection services)
{
services.AddDbContext<TbsDb>(options =>
options.UseSqlServer("someConnectionString"));
}
Затем я создаю новый класс, который наследует от исходного класса Startup и переопределяет этот метод для использования Sqlite, базы данных в памяти или чего-либо еще:
public override void SetupDbContext(IServiceCollection services)
{
services.AddDbContext<TbsDb>(
options => options.UseSqlite("someConnectionString"));
}
Это также хорошо работает с TestHost, если новый класс находится в том же проекте API.
Очевидно, я не хочу, чтобы этот класс, который используется для тестирования, был там. Но если я перенесу его в проект интеграционных тестов и создам там TestServer, тот же тест не пройден, потому что результат имеет статус 404. Почему это происходит? Он по-прежнему наследуется от класса Startup, который находится в проекте API. Таким образом, я ожидаю, что все маршруты будут работать одинаково, независимо от того, где находится класс TestStartup. Можно ли это как-то решить?