Pull to refresh

Comments 11

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

Золотые слова.
Я вообще считаю, что систему нужно тестировать тестами только на высоком уровне, и там где 1 тест убивает сразу мнооого зайцев.
Поддерживать 200-500 тестов то еще удовольствие…
Во-первых писать тесты нужно всех уровней — модульные, функциональные, сценарные. Оставив только последние вы оставите много кода без покрытия. Да и сообщение о зафейленых тестах будут не информативные. Лучше находить ошибки на уровне «маленьких» тестов.

>Поддерживать 200-500 тестов то еще удовольствие…

Значит работаете с нетестируемым кодом. Юнит-тесты должны быть очень легкими и тестировать только интерфейс модулей. Если тест повторяет логику кода, то это либо плохой код, либо плохой тест.
зато сообщение будет менее информативно. Более детальные тесты позволят сразу найти то, что сломалось
Крайне не согласен с автором статьи. Он рассуждает с позиций что юнит-тесты нужны для проверки написанного кода.
А они на самом деле нужны для проверки изменённого кода, чтобы убедиться что после изменений он работает как раньше. Это их главная и основная цель. А автор напрочь игнорит данный факт и расписывает исключительно этап производства продукта.
Почему игнорит? Просто это не озвучено явно. Например, про проблемы тестирования сильно связанных модулей (верхняя правая картинка) — на мой взгляд, очень актуально для написания тестов. Особенно с учетом того, что интерфейсы и реализация таких модулей, по наблюдениям, меняются очень часто. Получается — для того, чтобы поддерживать тесты в идеальном состоянии, придется постоянно вносить в них изменения, поскольку изменяется не только реализация, но и интерфейсы взаимодействующих кусочков. То есть, мы хотим поменять что-то в интерфейсе программы, и у нас есть тест, который мы также вынуждены изменять (а изменение теста при изменении интерфейса равносильно написанию теста с нуля). Таким образом, написание тестов более оправдано в местах, где интерфейс является стабильным, а необходимо поддерживать в основном стабильность реализации.
Автор, спасибо за статью, но почему статья в разделе ".NET"? Я никак с ним не связан, но рад, что прочел статью.
Решил поместил в .Net, потому что затрагивает ASP.NET MVC.
Про толстые контроллеры очень все верно сказано. У меня уже не первый случай, когда приходится сталкиваться с их появлением. Причем в некоторых случаях даже не знаешь, как подступиться к такому монстру, с чего начать рефакторинг.
Вынести бизнес логику из контроллера в модель или в слой бизнес-логики (если придерживаетесь POCO модели).
Sign up to leave a comment.

Articles