Проверка атрибута контроллера как при использовании [FromBody] дважды - PullRequest
Новая
       7

Проверка атрибута контроллера как при использовании [FromBody] дважды

0 голосов
/ 05 июня 2018

В ASP.NET MVC (независимо от версии, если это важно, предположим, что я использую последний Core 2.1), мы контролируем поведение и привязку параметров приложения, аннотируя контроллер с атрибутами, например, [HttpPost] дляметод, который должен вызываться как POST и [FromQuery] для параметра метода, который должен быть получен из строки запроса.

Теперь, когда я обнаружил трудный путь за последние месяцы, есть бесчисленное множество способов смешать это.Например, если у вас есть два параметра, объявленных как [FromBody], один всегда будет null, потому что только один может представлять тело.Или, если ваш метод помечен [HttpGet], ваш [FromBody] вернется null, потому что стандарт говорит, что это не так, как это делается.И поверьте мне, есть еще много способов ошибиться.

Я признаю, что это все мои ошибки.Если я сделаю это правильно, это сработает.Однако меня сбивает с толку то, что это то, что можно найти во время компиляции .В этом нет никаких зависимостей времени выполнения.И я узнаю, только когда отлаживаю, и это не работает.Я понимаю, что задача компилятора не состоит в том, чтобы найти логические недостатки в моей программе, но наверняка они могут быть найдены фабрикой контроллеров при ее создании?Модульный тест, в котором все типы контроллеров я добавляю в метод тестирования?Или такой инструмент, как статический анализ кода или stylecop?

Я погуглил и нашел ноль.Так что я предполагаю, что мои навыки Google не до этого.

Действительно ли в .NET Framework нет метода, позволяющего проверить, все ли атрибуты моего контроллера складываются в нечто, что может быть правильно обслужено?Неужели нет способа сказать мне, что я все это перемешал?

И если его действительно нет, то прежде чем я сам это напишу, это по какой-то причине?Если я сам написал это, есть ли какая-то известная причина, почему нельзя этого делать?

Ответы [ 2 ]

0 голосов
/ 21 марта 2019

Как оказалось, нет, там нет ничего, что делает то, что мне нужно, но ничто не мешает вам делать это самостоятельно.

Я написал хороший маленький библиотечный класс, которым я могу кормить свои контроллерыв модульном тесте, и он выдаст мне поток ошибок, которые затем приведут к провалу теста.

Код для класса, хотя и написан мной, не мой, а мои работодатели, поэтому я не могу опубликовать его здесь, но в этом нет ничего особенного, просто много размышлений о проверке атрибутов открытых методов и ихпараметры, удостоверяющие, что они совпадают.Так что да, это возможно, в этом нет ничего особенного, если вам это нужно так же сильно, как и мне, просто напишите себе аккуратный маленький статический класс CheckCorrectUsageOfAttributes с помощью универсального метода ForController и напишите такие тесты:

/// <summary>
/// Tests the account controller.
/// </summary>
[TestMethod]
public void TestAccountController()
{
    // arrange

    // act
    var result = CheckCorrectUsageOfAttributes.ForController<AccountController>();

    // assert
    var first = result.FirstOrDefault();
    Assert.IsNull(first, first);
}
0 голосов
/ 06 июня 2018

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

https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-2.1

...