Кто-То тестирует контроллеры? На сколько это целесообразно? В плане, зачем

тестировать контроллер если можно оттестировать сервис внутри него.

что бы убедиться что контроллер не сломался? 😃

Ну дак если у тебя сервис обработчик не сломался, то и контроллеру/ендпоинту чего ломаться?)

у меня например контроллер далеко не всегда просто сервис дёргает 🤷‍♂️

Ну согласен у меня к примеру иногда и userId доставал, но ради этого стоит целый ендпоинт тестировать?

Шоб 100% покрытие тестами было)

https://andrewlock.net/should-you-unit-test-controllers-in-aspnetcore/

https://docs.microsoft.com/en-us/aspnet/core/mvc/controllers/testing?view=aspnetcore-6.0

А как же no bussiness logic in controller? Вообще контроллеры должны быть очень простыми, желательно там должен только метод сервиса вызываться.

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

Во всем есть исключение

Нужно их по-умному отлавливать

Хехех, понятно) А как же ревьюверы такое пропустили?

Я от таких проектов выгораю, хотя и сам когда то таким был

Логично предположить, что в компаниях такого плана нет культуры ревью. Как пример, я работал в прекрасной продуктовой галере местного разлива, где нужно было ходить по двум этажам офиса и спрашивать, не коммитит ли кто-то изменения на базе, потому что edmx потом не мерджится. А всё потому, что единственный сИнЬеР разработчик придумал, что проще всего коммитить на мастер всем без исключения с поправкой на GA, что код компилится

Я благодаря такому вырос и понял как не нужно. И когда попал в Вери биг корпо с идеально налаженными процессами, жадно потреблял информацию о том, как должно быть.

Жесть какая, всё больше понимаю как мне повезло, что сразу после курсов попал в компанию с налаженными процессами, слаком и т.д.)

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

Согласен, твой случай приятнее второго)

Ну во первых ты тестируешь валидацию входящих данных Она встроена в асп и не имеет отношения к логике контроллера (а иногда даже имеет, если валидация требует бегать например в бд для проверки существования чего-то) Во вторых ты тестируешь также коды ответов, которые возвращает эндпоинт Бывает на один эндпоинт около 7-10 возможных кодов ответов В третьих тестируя контроллер, ты тестируешь весь флоу приложения Т.е. весь Startup.Configure метод + все связанные с mvc middleware штуки (например mvc filters) Это такого рода глобальные тесты, чтобы убедиться, что ничего не сломалось, когда логика действительно трудная и комплексная (Речь об интеграционных тестах контроллеров с использованием TestHost)

Ну интеграцтонные тесты да, это же не юнит, ответы в них конечно тестируем. Хотя непонятно о каких тестах человек спрашивал.

Микрософт так не думает

кто тебе такое сказал