Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
То, что вы называете E2E, являются более важными, чем остальные тесты. UI вряд ли нужен вообще, если есть E2E. С Unit тестами тоже не стоит сходить с ума, они должны быть, но…
Не переборщите, сейчас много повторяют мантру, что нужно тдд и иметь 100% покрытие тестами и все будет как надо. Но тут есть вторая сторона медали, некоторые куски кода, как ни крути, будут покрыты на 200, 300 и если во время не остановиться то и 5000%, не предел, то есть они будут проверяться больше, чем один раз в разных тестах. Чем это плохо? что любое изменение в этом коде, потребует кропотливых коррекций в упавших юнит тестах, а это время. Поэтому тестов должно быть разумное количество и проверять они должны в первую очередь наиболее критичные вещи.
И ответ есть — больше Unit тестов!
Не переборщите, сейчас много повторяют мантру, что нужно тдд и иметь 100% покрытие тестами и все будет как надо. Но тут есть вторая сторона медали, некоторые куски кода, как ни крути, будут покрыты на 200, 300 и если во время не остановиться то и 5000%, не предел, то есть они будут проверяться больше, чем один раз в разных тестах. Чем это плохо? что любое изменение в этом коде, потребует кропотливых коррекций в упавших юнит тестах, а это время. Поэтому тестов должно быть разумное количество и проверять они должны в первую очередь наиболее критичные вещи.
Каждый тип тестов несет свою функцию. Unit тесты важны для быстрого подтверждения, что не наблюдается регресс после изменения кода
E2E важны для проверки бизнес процесса.
В общем случае одно другое не заменяет. Но «немного» перегнув палку можно одним подходом частично скомпенсировать отсутствие другого.
Это как при отсутствии дома купить огромную тачку и спать там:)
E2E важны для проверки бизнес процесса.
В общем случае одно другое не заменяет. Но «немного» перегнув палку можно одним подходом частично скомпенсировать отсутствие другого.
Это как при отсутствии дома купить огромную тачку и спать там:)
Не будут и не должны они быть покрыты ни на 200 ни на 300 ни тем более 5000%,
если разберетесь с тем, как работать с инверсией зависимостей и как правильно писать юнит-тесты, где зависимости представлены заглушками.
О, привет из 2017го)
Я немного не об этом, для юнита, для каждого из сценариев есть свой тест. Формально, чтобы добиться 100% покрытия, а в 2017м году бытовало мнение, что только 100% покрытия спасут мир, нужно чтобы юнит тест прошелся по каждой строке в коде, хотя бы в одном сценарии. Из за этого общий код, который исполняется во всех сценариях, будет тестироваться многократно, и это приводит к тому, что общие куски кода тестируются больше чем 1 раз, а это в свою очередь приводит к тому, что небольшое изменение в общем коде, ломало больше чем 1 тест, хорошо если их 2, а если 10? А если 100? На фикс которых нужно тратить время и силы. Нужно было в 2017м, сейчас конечно такой проблемы нет, ии все фиксит.
100% покрытие нужно было для овноменеджеров, которым надо было выпендриться перед начальством. Вон какой молодец я - заставил команду на 100% покрыть код тестами. Тут согласен.
Но я так и не понял, почему код будет тестироваться много раз, если его просто изначально писать нормально и использовать заглушки для зависимостей. Не по 300, 500 строк в методе, а чисто для выполнения конкретной задачи.
Я думаю, что они спят на земле, потому что их заставляют построить небоскреб и иначе никак, а это тяжело, хотя в большинстве случаев достаточно 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 :)
По опыту, e2e тесты подходят для проектов, написанных кривыми руками. Но это примерно 90% всех написанных когда-либо приложений.
Если грамотно строить архитектуру проекта, где вся презентационная и бизнес логика юнит-тестируема, а классы и функции не разрастаются до сумасшедших размеров, то в большинстве случаев до e2e тестов скорее всего не дойдет.
Также в этом случае все становится настолько прозрачным и понятным, что самих юнит тестов много не требуется. Тестируются в этом случае только критически важные и сложные функции, где есть действительно большой риск ошибиться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
UI тесты — всегда ли нужны?