Что такое endpoint тестирование

Что проверяют

Понимаете ли вы, что именно тестируется на уровне HTTP-контракта, и отделяете ли это от юнит-теста контроллера. За вопросом обычно стоит практика: писали ли вы интеграционные тесты веб-API и как поднимали приложение внутри теста.

Как отвечать

Endpoint-тестирование это проверка API снаружи, реальным запросом к конечной точке: маршрут и метод, параметры и тело, заголовки, код ответа, форма и содержимое ответа. Тест ничего не знает про внутренние классы и фиксирует контракт, а не реализацию.

В ASP.NET Core для этого есть WebApplicationFactory<TProgram> из пакета Microsoft.AspNetCore.Mvc.Testing: он поднимает приложение в памяти целиком, вместе с контейнером зависимостей, конвейером middleware, фильтрами и привязкой модели, а клиент из него ходит по маршрутам без реального сокета и порта.

var client = factory.CreateClient();
var response = await client.GetAsync("/api/users/42");
Assert.Equal(HttpStatusCode.OK, response.StatusCode);
var user = await response.Content.ReadFromJsonAsync<UserDto>();

Дальше перечислите объём проверок: успешный сценарий, валидация с ответом 400 и телом ProblemDetails, отсутствующий ресурс с 404, разделение 401 и 403, поведение при повторной отправке запроса. Внешние зависимости подменяются переопределением регистраций в тестовом хосте, база поднимается в контейнере или заменяется тестовой схемой.

Где спотыкаются

Валят в одну кучу функциональную проверку, нагрузку и поиск уязвимостей. Это разные работы с разными инструментами и разной периодичностью, и такой ответ читается как пересказ статьи, а не как опыт.

Проверяют только код ответа. Двухсотый статус с пустым или неполным телом ломает клиента ровно так же, как пятисотый, поэтому в утверждениях должна быть и форма ответа, а не один статус.

Подменяют заглушками всё подряд, включая собственный слой доступа к данным. Тогда тест перестаёт отличаться от юнит-теста контроллера и не ловит именно то, ради чего затевался: маршрутизацию, сериализацию, фильтры и политику авторизации.