Явное добавление контроллера в собственный WebAPI Owin
В настоящее время я провожу несколько модульных тестов, и часть их функций - это вызов API (это слишком много и слишком важно для работы, чтобы полностью объяснить, что он здесь делает ...).
По сути, API получит запрос, выполнит некоторую обработку и перешлет этот запрос соответствующей стороне.
Мне нужно протестировать этот код, абстрагировать его нецелесообразно, так как он уже довольно хорошо абстрагирован, но есть некоторые жесткие зависимости от HttpClient, которые я не могу удалить (на каком-то этапе мне придется его назвать ...).
Я использую Owin TestServer для создания сервера webapi в памяти,
См. Strathweb здесь: https://www.strathweb.com/2013/12/owin-memory-integration-testing/
Дэвид Уитни здесь: http://www.davidwhitney.co.uk/Blog/2015/01/07/testing-an-asp-net-webapi-app-in-memory/
и DontCodeTired: http://dontcodetired.com/blog/post/In-Process-Http-Server-for-Integration-Test-Faking-with-Owin-Katana-and-WebAPI
Моя проблема заключается в том, что сервер WebApi, который я создаю для отправки запросов, будет автоматически обнаруживать другой API в проекте и запускать запросы против него, а не использовать мой модульный тестовый / макетный контроллер.
Как я могу использовать объект HttpConfiguration, используемый в классе WebApp.Start<**Startup**>(), для использования только одного контроллера? Я имею в виду этот класс:
internal class Startup
{
public void Configuration(IAppBuilder app)
{
var config = new HttpConfiguration();
config.MapHttpAttributeRoutes();
config.EnsureInitialized();
config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
app.UseWebApi(config);
}
}
Я не понимаю, как решить эту проблему, поскольку во всех примерах в Интернете говорится о сопоставлении маршрутов HTTP, а не об удалении / добавлении маршрутов вручную.
Если у вас есть вопросы / критические замечания, пожалуйста, добавьте комментарий, и я обновлю вопрос, насколько смогу, я чувствую, что могу быть немного ограничен в том, что я могу публиковать из-за работы.
Ответы 1
У меня есть решение, и я думаю, что это опрятное ..
На основе блога Strathweb: https://www.strathweb.com/2013/08/customizing-controller-discovery-in-asp-net-web-api/
Я реализовал собственный DefaultAssembliesResolver, который исключает сборку, содержащую другой контроллер API, вызывающий эти проблемы.
Пользовательский преобразователь:
public class MyAssembliesResolver : DefaultAssembliesResolver
{
public override ICollection<Assembly> GetAssemblies()
{
ICollection<Assembly> baseAssemblies = base.GetAssemblies();
List<Assembly> assemblies = new List<Assembly>(baseAssemblies.Where(x=>!x.FullName.Contains("<nameOfAssemblyToExclude>")));
return assemblies;
}
}
затем замените преобразователь по умолчанию в классе запуска:
config.Services.Replace(typeof(IAssembliesResolver), new MyAssembliesResolver());
Это позволило мне исключить дополнительный производственный ApiController (который я пытаюсь протестировать) и включить только мой ApiController для модульного тестирования в конвейер памяти Owin.