К каждому из трех представленных "абстрагированных от рутины" тестов есть вопросы:
Handle_HappyPath_DoesNotThrow
Все зависимости класса подменены. В какой ситуации этот метод может бросить исключение? Я вижу 2 варианта:
Ошибка валидации входных данных - см. ниже.
NRE от мока. Следовательно, тест проверяет не бизнес-логику, а вашу реализацию моков, насколько качественно они имитируют поведение сервисов в сценарии happy path. Что не имеет практической ценности.
Я видел слишком много неудачных примеров использования декораторов/интерсепторов на "не самых простеньких проектах", чтобы считать их наличие плюсом. Скорее хорошо, что в стандартном DI контейнере этого нет.
Вы даже листинги кода взяли из официальной документации по FluentValidation. Вам не кажется, что для статьи на Хабр нужно приложить чуть больше усилий?
проблема "ненужных" зависимостей устраняется атрибутом [FromServices], соответственно minimal api экономит только на создании самого контроллера, как уже заметили выше.
OK, вы разделили маппинг на секции. Логически это чем-нибудь отличается от разделения экшенов по отдельным контроллерам? Принудительным использованием fluent builder вместо атрибутов?
Тем не менее, использование MediatR ухудшает читаемость кода. Хотя бы потому, что возможно добиться аналогичной организации кода, руководствуясь банальным SOLID, при этом избежав проблемы поиска "а какой класс в проекте реализует вот тот дженерик интерфейс с таким то параметром", что особенно сильно проявляется на больших проектах.
Про удобство: возьмем типичный не очень микро сервис с сотней-другой эндпоинтов, обвешанных атрибутами авторизации, кастомной сериализации, подсказками для OpenAPI и прочей часто встречающейся в энтерпрайз-разработке логикой. Перенос всего этого в один файл (или предполагается разбитие файла на секции?) значительно ухудшит и удобство, и наглядность. Даже при использовании максимально тонких контроллеров.
Предпочитаю 16'. В рюкзак все еще влезает, т.е. мобильность лично мою никак не портит. А каждый сантиметр по вертикали добавляет комфорта, особенно если стационарного места на ближайшее время не предвидится.
По примерам кода выше уже проехались. Добавлю, что тема очень избитая, и сказать что-то новое (а иначе зачем писать статью, особенно на Хабр) достаточно сложно. Плюс, декоратор - сам по себе популярный и многим известный паттерн, и с его вариациями в DI, в сторонних библиотеках типа MediatR, или просто работая с middleware pipeline - сталкивались многие. Поэтому, опытному разработчику эта статья не нужна, а новичку я бы рекомендовал прочитать любой популярный гайд/курс/книгу по паттернам. Если очень хочется именно C# и на русском языке - есть прекрасная книга Сергея Теплякова. Да хотя бы статья на википедии.
В чем ценность именно этого коротенького перевода, состоящего из 2 не самых удачных примеров кода? Получился бы более достойный хабра материал при склейке всех переводов в одну статью.
Как раз воспользоваться options.ValidateOnBuild - максимально дешево, один раз написать тест на сборку контейнера. Все интеграционные тесты через TestHost также свалятся, если валидация контейнера не прошла. Да и ваш SetUpServiceProvider свалится.
Эта валидация не покрывает многие кейсы, часть из них я упомянул в заключении.
Можете пример привести, когда контейнер пройдет валидацию, но не пройдет ваш тест? Т.е. в чем практическая польза предложенного метода. Проверка зависимостей контроллеров - не принимается, поскольку из коробки есть
нельзя не задать встречный вопрос: когда сменивший вид деятельности (например, продвинувшийся по карьерной лестнице) человек перестает быть программистом, т.е. теряет соответствующую компетенцию?
К каждому из трех представленных "абстрагированных от рутины" тестов есть вопросы:
Все зависимости класса подменены. В какой ситуации этот метод может бросить исключение? Я вижу 2 варианта:
Ошибка валидации входных данных - см. ниже.
NRE от мока. Следовательно, тест проверяет не бизнес-логику, а вашу реализацию моков, насколько качественно они имитируют поведение сервисов в сценарии happy path. Что не имеет практической ценности.
Если вынести проверку входных данных в валидатор, данный тест заменяется легковесным юнит-тестом валидатора.
Что проверяет этот тест, если провайдер данных замокан?
Поскольку иллюстрации взяты из статьи https://blog.bytebytego.com/p/from-monolith-to-microservices-key (за пэйволлом), опубликованной 2 днями ранее, то я предполагаю, что содержимое сдернуто оттуда же.
Неверно. Но раз уж опускаться до аналогий... никто не говорил, что "молоток плохой".
Я видел слишком много неудачных примеров использования декораторов/интерсепторов на "не самых простеньких проектах", чтобы считать их наличие плюсом. Скорее хорошо, что в стандартном DI контейнере этого нет.
del
Где-то я этот формальный стиль изложения уже видел... https://docs.fluentvalidation.net/en/latest/
А далее в статье идет перевод https://docs.fluentvalidation.net/en/latest/start.html.
Вы даже листинги кода взяли из официальной документации по FluentValidation. Вам не кажется, что для статьи на Хабр нужно приложить чуть больше усилий?
проблема "ненужных" зависимостей устраняется атрибутом [FromServices], соответственно minimal api экономит только на создании самого контроллера, как уже заметили выше.
OK, вы разделили маппинг на секции. Логически это чем-нибудь отличается от разделения экшенов по отдельным контроллерам? Принудительным использованием fluent builder вместо атрибутов?
Тем не менее, использование MediatR ухудшает читаемость кода. Хотя бы потому, что возможно добиться аналогичной организации кода, руководствуясь банальным SOLID, при этом избежав проблемы поиска "а какой класс в проекте реализует вот тот дженерик интерфейс с таким то параметром", что особенно сильно проявляется на больших проектах.
Влияет ли minimal api на производительность?
Про удобство: возьмем типичный не очень микро сервис с сотней-другой эндпоинтов, обвешанных атрибутами авторизации, кастомной сериализации, подсказками для OpenAPI и прочей часто встречающейся в энтерпрайз-разработке логикой. Перенос всего этого в один файл (или предполагается разбитие файла на секции?) значительно ухудшит и удобство, и наглядность. Даже при использовании максимально тонких контроллеров.
почему?
Предпочитаю 16'. В рюкзак все еще влезает, т.е. мобильность лично мою никак не портит. А каждый сантиметр по вертикали добавляет комфорта, особенно если стационарного места на ближайшее время не предвидится.
Это буквально первая задача из гайда литкода для абсолютных начинающих. Своеобразный hello world. Попробуйте задачи уровня Hard.
По примерам кода выше уже проехались. Добавлю, что тема очень избитая, и сказать что-то новое (а иначе зачем писать статью, особенно на Хабр) достаточно сложно. Плюс, декоратор - сам по себе популярный и многим известный паттерн, и с его вариациями в DI, в сторонних библиотеках типа MediatR, или просто работая с middleware pipeline - сталкивались многие. Поэтому, опытному разработчику эта статья не нужна, а новичку я бы рекомендовал прочитать любой популярный гайд/курс/книгу по паттернам. Если очень хочется именно C# и на русском языке - есть прекрасная книга Сергея Теплякова. Да хотя бы статья на википедии.
del
Нейропортреты сейчас в тренде :) а справится ли нейросеть, например, с генерацией спрайтов для 2D графики?
В чем ценность именно этого коротенького перевода, состоящего из 2 не самых удачных примеров кода? Получился бы более достойный хабра материал при склейке всех переводов в одну статью.
Как раз воспользоваться options.ValidateOnBuild - максимально дешево, один раз написать тест на сборку контейнера. Все интеграционные тесты через TestHost также свалятся, если валидация контейнера не прошла. Да и ваш SetUpServiceProvider свалится.
Можете пример привести, когда контейнер пройдет валидацию, но не пройдет ваш тест? Т.е. в чем практическая польза предложенного метода. Проверка зависимостей контроллеров - не принимается, поскольку из коробки есть
После которого зависимости контроллеров будут валидироваться самим контейнером.
способ есть https://andrewlock.net/new-in-asp-net-core-3-service-provider-validation/
нельзя не задать встречный вопрос: когда сменивший вид деятельности (например, продвинувшийся по карьерной лестнице) человек перестает быть программистом, т.е. теряет соответствующую компетенцию?