Комментарии 5
То, что вы называете E2E, являются более важными, чем остальные тесты. UI вряд ли нужен вообще, если есть E2E. С Unit тестами тоже не стоит сходить с ума, они должны быть, но…
Не переборщите, сейчас много повторяют мантру, что нужно тдд и иметь 100% покрытие тестами и все будет как надо. Но тут есть вторая сторона медали, некоторые куски кода, как ни крути, будут покрыты на 200, 300 и если во время не остановиться то и 5000%, не предел, то есть они будут проверяться больше, чем один раз в разных тестах. Чем это плохо? что любое изменение в этом коде, потребует кропотливых коррекций в упавших юнит тестах, а это время. Поэтому тестов должно быть разумное количество и проверять они должны в первую очередь наиболее критичные вещи.
И ответ есть — больше Unit тестов!
Не переборщите, сейчас много повторяют мантру, что нужно тдд и иметь 100% покрытие тестами и все будет как надо. Но тут есть вторая сторона медали, некоторые куски кода, как ни крути, будут покрыты на 200, 300 и если во время не остановиться то и 5000%, не предел, то есть они будут проверяться больше, чем один раз в разных тестах. Чем это плохо? что любое изменение в этом коде, потребует кропотливых коррекций в упавших юнит тестах, а это время. Поэтому тестов должно быть разумное количество и проверять они должны в первую очередь наиболее критичные вещи.
Каждый тип тестов несет свою функцию. Unit тесты важны для быстрого подтверждения, что не наблюдается регресс после изменения кода
E2E важны для проверки бизнес процесса.
В общем случае одно другое не заменяет. Но «немного» перегнув палку можно одним подходом частично скомпенсировать отсутствие другого.
Это как при отсутствии дома купить огромную тачку и спать там:)
E2E важны для проверки бизнес процесса.
В общем случае одно другое не заменяет. Но «немного» перегнув палку можно одним подходом частично скомпенсировать отсутствие другого.
Это как при отсутствии дома купить огромную тачку и спать там:)
Я думаю, что они спят на земле, потому что их заставляют построить небоскреб и иначе никак, а это тяжело, хотя в большинстве случаев достаточно 3х этажного домика. Небоскреб это аллегория на идею 100% покрытия юнит тестами, которое последнее время преподносится, как решение всех проблем. Но на практике у такого подхода есть высокая цена — время. При этом, чтобы получить высокое качество кода, вовсе не обязательно заглядывать под каждый куст. Разумеется при этом нельзя писать тесты бездумно, например покрыть 50% и хватит, нет, нужно пытаться написать минимум тестов, которые тестируют максимум возможных сценариев. А какой там процент выйдет, дело десятое. Чем шире сценарий, тем лучше. Наша цель не выточить идеальные шестеренки, наша цель, чтобы мотор собранный из этих шестеренок, работал как надо. Второй момент, который дают юнит тесты, это не только тестирование работоспособности кода, но так же они заставляют вас делать код модулярным, думать о зависимостях. Поэтому на мой взгляд, иногда достаточно всего одного теста на юнит, который покрывает пусть небольшой процент, тесты потом если понадобится, можно будет написать, но при этом он уже сделал свое дело и заставил вас спроектировать этот юнит максимально независимым от других, продумать api и так далее. И это большое дело.
Оптимальное покрытие автотестами — тема на самом деле важная, но сложная для понимания. Единственный ориентир, известный мне (пирамида тестирования) неплох, но несовершенен.
В зависимости от внутреннего устройства приложения необходимость тех или иных типов автотестов варьируется.
Мы хотим делать БОЛЬШЕ unit тестов не потому, что любим их, а потому, что они самые быстрые и точные. Весь функционал, который можно покрыть unit тестами лучше всего ими же и покрыть.
Тем не менее, многие вещи unit тесты покрыть не в состоянии, к примеру — конфигурацию Spring контекста, валидации, аннотации, интеграцию со сторонними либами. Иногда доходило до того, что мне удобнее было написать свой велосипед покрытый юнит тестами, чем корячится и покрывать тот же функционал, реализованный с помощью сторонней библиотеки интеграционным тестом. (пример — собственный маппер для разных классов против готовых мапперов, аля orika)
Многие используют мантру «нельзя все покрыть unit тестами» или «зачем дублировать что-то на уровне unit тестов если можно все сразу проверить с UI». Для того, чтоб разобраться с первым кейсом я рекомендую попробовать ради интереса разработать какую-то фичу используя TDD и добавлять тесты уровнем выше только если это реально необходимо. Со вторым я даже не вижу смысла бороться — нет ничего печальнее и поучительнее чем мучительная поддержка uber-свита тестов на уровне UI :)
В зависимости от внутреннего устройства приложения необходимость тех или иных типов автотестов варьируется.
Мы хотим делать БОЛЬШЕ unit тестов не потому, что любим их, а потому, что они самые быстрые и точные. Весь функционал, который можно покрыть unit тестами лучше всего ими же и покрыть.
Тем не менее, многие вещи unit тесты покрыть не в состоянии, к примеру — конфигурацию Spring контекста, валидации, аннотации, интеграцию со сторонними либами. Иногда доходило до того, что мне удобнее было написать свой велосипед покрытый юнит тестами, чем корячится и покрывать тот же функционал, реализованный с помощью сторонней библиотеки интеграционным тестом. (пример — собственный маппер для разных классов против готовых мапперов, аля orika)
Многие используют мантру «нельзя все покрыть unit тестами» или «зачем дублировать что-то на уровне unit тестов если можно все сразу проверить с UI». Для того, чтоб разобраться с первым кейсом я рекомендую попробовать ради интереса разработать какую-то фичу используя TDD и добавлять тесты уровнем выше только если это реально необходимо. Со вторым я даже не вижу смысла бороться — нет ничего печальнее и поучительнее чем мучительная поддержка uber-свита тестов на уровне UI :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
UI тесты — всегда ли нужны?