Комментарии 11
ведь практически все хорошо зарекомендовавшие себя подходы в разных областях жизни на самом деле эффективны лишь при определённых обстоятельствах, и лишаются своих преимуществ в других условиях
Золотые слова.
Золотые слова.
+3
Я вообще считаю, что систему нужно тестировать тестами только на высоком уровне, и там где 1 тест убивает сразу мнооого зайцев.
Поддерживать 200-500 тестов то еще удовольствие…
Поддерживать 200-500 тестов то еще удовольствие…
0
Во-первых писать тесты нужно всех уровней — модульные, функциональные, сценарные. Оставив только последние вы оставите много кода без покрытия. Да и сообщение о зафейленых тестах будут не информативные. Лучше находить ошибки на уровне «маленьких» тестов.
>Поддерживать 200-500 тестов то еще удовольствие…
Значит работаете с нетестируемым кодом. Юнит-тесты должны быть очень легкими и тестировать только интерфейс модулей. Если тест повторяет логику кода, то это либо плохой код, либо плохой тест.
>Поддерживать 200-500 тестов то еще удовольствие…
Значит работаете с нетестируемым кодом. Юнит-тесты должны быть очень легкими и тестировать только интерфейс модулей. Если тест повторяет логику кода, то это либо плохой код, либо плохой тест.
+3
зато сообщение будет менее информативно. Более детальные тесты позволят сразу найти то, что сломалось
+2
Крайне не согласен с автором статьи. Он рассуждает с позиций что юнит-тесты нужны для проверки написанного кода.
А они на самом деле нужны для проверки изменённого кода, чтобы убедиться что после изменений он работает как раньше. Это их главная и основная цель. А автор напрочь игнорит данный факт и расписывает исключительно этап производства продукта.
А они на самом деле нужны для проверки изменённого кода, чтобы убедиться что после изменений он работает как раньше. Это их главная и основная цель. А автор напрочь игнорит данный факт и расписывает исключительно этап производства продукта.
-1
Почему игнорит? Просто это не озвучено явно. Например, про проблемы тестирования сильно связанных модулей (верхняя правая картинка) — на мой взгляд, очень актуально для написания тестов. Особенно с учетом того, что интерфейсы и реализация таких модулей, по наблюдениям, меняются очень часто. Получается — для того, чтобы поддерживать тесты в идеальном состоянии, придется постоянно вносить в них изменения, поскольку изменяется не только реализация, но и интерфейсы взаимодействующих кусочков. То есть, мы хотим поменять что-то в интерфейсе программы, и у нас есть тест, который мы также вынуждены изменять (а изменение теста при изменении интерфейса равносильно написанию теста с нуля). Таким образом, написание тестов более оправдано в местах, где интерфейс является стабильным, а необходимо поддерживать в основном стабильность реализации.
0
Автор, спасибо за статью, но почему статья в разделе ".NET"? Я никак с ним не связан, но рад, что прочел статью.
+3
Про толстые контроллеры очень все верно сказано. У меня уже не первый случай, когда приходится сталкиваться с их появлением. Причем в некоторых случаях даже не знаешь, как подступиться к такому монстру, с чего начать рефакторинг.
0
Сорри, но…
-5
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Избирательное юнит-тестирование или ещё раз о тонких контроллерах