Проблема сквозных тестов
Соль отличная. Согласно Википедии, соль необходима для жизни в целом, а соленость - один из основных человеческих вкусов.
Большинство людей готовят пищу с поваренной солью. Однако, если вы добавите в еду слишком много или слишком мало соли, вам, скорее всего, будет трудно есть такую еду.
Это не делает соль плохой. Является ли? Нет, его просто нужно добавить в нужном количестве.
Помимо правильного количества, существуют медицинские условия, при которых вам рекомендуется либо уменьшить потребление соли, либо полностью отказаться от нее.
Итак, вредна ли соль только потому, что кого-то попросили избавиться от нее?
Я не практикующий врач, но может и нет.
То же самое можно сказать и о сквозных тестах. Они отлично подходят для тестирования программного обеспечения, но у них есть свои проблемы. Слишком много или слишком мало - тоже не на пользу.
Прежде чем продолжить, знаете ли вы, что такое сквозные тесты?
Что такое сквозные тесты?
Из всех тестов, я думаю, что сквозные тесты довольно легко понять интуитивно.
Если у вас есть банковское приложение, в котором пользователь может снимать деньги со своего счета, как показано ниже:
Вы можете написать сквозной тест, который проверяет, действительно ли пользователь может снимать деньги, то есть без ошибок.
В интерфейсном приложении сквозное тестирование автоматизирует браузер и проверяет, работают ли определенные функции, при этом выдавая себя за пользователя.
В псевдокоде тестовый файл может выглядеть так:
const testWithdrawal = (browser) => {
browser
.goToURL("http://localhost:3000")
.click("button-1")
.expect("#amount")
.toContainText(2490701)
}Тест действует как настоящий пользователь. Он запускает браузер и посещает URL-адрес, по которому загружено приложение. Он также имитирует нажатие на кнопку вывода средств, а затем делает утверждение, чтобы подтвердить, что окончательная сумма равна предыдущей сумме минус 10000.
Довольно легко понять.
Итак, в чем же настоящая проблема со сквозным тестированием?
Какие проблемы?
Сквозные тесты - это мощный вид тестов. Они экономят много времени при тестировании функций в целом.
Фактически, если вы когда-либо искали различные типы тестов для интерфейсного приложения, вы, скорее всего, встретили бы «пирамиду тестирования», которая выглядит следующим образом:
По сути, сквозные тесты преподносятся как наиболее полезный вид тестов.
Это правда, но если вы новичок в тестировании в целом, вы можете неправильно истолковать предыдущее утверждение.
Возможно, вы не увидите необходимости в других типах тестов. Или, что еще хуже, у вас может возникнуть соблазн отказаться от модульных и (или) интеграционных тестов в пользу просто «чрезвычайно полезного вида тестов» - сквозных тестов.
Непосредственно перед тем, как вы ошибетесь в интерпретации сквозных тестов, обратите внимание на следующее:
1. Сквозные тесты медленные
Думаю об этом. Запуск браузера, загрузка приложения, установка некоторого состояния, имитация пользовательских щелчков и т. Д. Это может занять некоторое время!
На самом деле нередко выполнение набора сквозных тестов занимает около 30 минут.
Хотя вы можете подумать, что это не так уж и много времени, помните, что при разработке приложений в большинстве случаев вам нужна немедленная обратная связь.
Эта новая функция нарушает существующую функциональность? Все работает как положено?
Вам нужен быстрый ответ, и если каждый раз на это у вас уходит 30 минут, вам нужно проявить терпение.
Если вы ошиблись, думая, что сквозные тесты - это единственный вид тестов, который вам нужен, возможно, вы написали слишком много из них, что может занять несколько часов, чтобы полностью запустить ваши наборы тестов.
Согласитесь, это не лучший способ быстро получать повторяющуюся обратную связь.
2. Сквозные тесты чаще терпят неудачу.
Предполагая, что вы знаете, что такое модульный тест, хорошо написанный модульный тест, запускаемый сто раз, скорее всего, будет успешным, если тесты будут детерминированными и в кодовую базу не будет внесено никаких изменений.
Приведенное выше утверждение верно для модульных тестов, но этого нельзя сказать о сквозных тестах.
Итак, что я имею в виду, говоря, что они терпят неудачу чаще?
У вас может произойти сбой сквозного теста, тогда как тестируемый код работает должным образом. Багов нет. Ничего плохого. Тогда почему сквозной тест не прошел?
Что ж, код, возможно, занял слишком много времени для выполнения, API, возможно, потребовалось больше времени для ответа или временно отключился, и он продолжает работать.
Это проблема не только для сквозных тестов. Эти проблемы возникают из-за множества внешних зависимостей.
Сквозные тесты - это здорово, но имейте в виду, что они могут потерпеть неудачу, даже если ваш код работает так, как ожидалось.
Знаешь, это как если бы этот странный начальник был счастлив с тобой сегодня, а завтра хмуро смотрит на тебя, как будто видел привидение. Вы не сделали ничего плохого, вы тот же человек, просто они не очень надежны в своем настроении.
Теперь вы поняли суть.
3. Отладка сквозных тестов может быть сложной.
Отладка. Мы все любим отладку, верно? Конечно нет. Если бы мне не приходилось тратить так много времени на отладку кода, я бы отправил новые функции за считанные минуты. Ух, это натянуто.
Отладка сквозных тестов иногда может быть настоящей проблемой. Помимо необходимости открывать браузер и очень стараться воспроизвести ошибку, вы можете испытать большее разочарование, если ваш тест завершится неудачно на другой машине, например, на сервере CI.
Чтобы обуздать такие разочарования, очень часто сквозные тесты запускаются в воспроизводимой среде, такой как контейнер докеров.
Вы видите, насколько выросла ваша база знаний для проведения сквозных тестов? Что ж, это может быть непросто и для младших разработчиков. В любом случае, я думаю, это им на пользу. Их заставят учиться на работе, но им придется помнить о необходимости дополнительного обучения.
4. Сквозные тесты писать сложнее.
Я бы не стал подчеркивать этот момент, поскольку вы, вероятно, уже это знаете. Стоит просто повторить, что для набора сквозных тестов обычно требуется больше времени для настройки и написания, чем для других видов тестов, а именно модульных тестов, интеграционных тестов и тестов моментальных снимков.
Среди проблем…
Не поймите неправильно суть этой статьи. Я не против сквозных тестов. Они потрясающие. Однако, если вы новичок в тестировании, легко подумать, что они лучшие спасители, у которых нет никаких недостатков.
Что ж, это не так, и именно поэтому хороший набор тестов должен содержать правильное сочетание тестов.
Это все равно, что приготовить тарелку супа. Вода - это здорово, но если налить слишком много воды во время приготовления супа, вы получите болезненный ужин. Каждый ингредиент необходимо добавлять в правильной пропорции. Хотя «правильная пропорция» в основном субъективна, обычно есть приятная часть, с которой каждый может смириться.
То же самое можно сказать и о написании тестов в целом.
Пишите больше модульных тестов, меньше тестов моментальных снимков / интеграционных тестов и еще меньше сквозных тестов.
Заключение
Понимая, почему «отличные» сквозные тесты не должны заменять весь ваш набор тестов, приступайте к написанию приложений со сбалансированным набором тестов и, надеюсь, с меньшим количеством ошибок.
Селах!
