что такое сквозное тестирование e2e
Знакомство с фронтенд-тестированием. Часть третья. E2E-тестирование
Авторизуйтесь
Знакомство с фронтенд-тестированием. Часть третья. E2E-тестирование
Рассказывает Гил Тайяр, автор блога на Hackernoon
В этой части мы рассмотрим сквозное (E2E) тестирование: протестируем всё приложение целиком, причём сделаем это с точки зрения пользователя, по сути, автоматизируя все его действия.
В нашем случае приложение состоит только из фронтенда — бэкенда попросту нет, поэтому E2E-тестирование будет заключаться в открытии приложения в реальном браузере, выполнении набора вычислений и проверке валидности значения на экране.
Нужно ли проверять все перестановки, как мы делали это в юнит-тестах? Нет, ведь это уже проверено! В E2E-тестах мы проверяем работоспособность не отдельных юнитов, а всей системы сразу.
Сколько нужно E2E-тестов?
Первая причина, по которой таких тестов не должно быть много, — хорошо написанных интеграционных и юнит-тестов должно хватить. E2E-тесты должны проверить, что все элементы корректно связаны между собой.
3–4 декабря, Онлайн, Беcплатно
Вторая причина — они медленные. Если их будет сотня, как юнит-тестов и интеграционных, то тестирование будет проходить очень долго.
Третья причина — непредсказуемое поведение E2E-тестов. О таком явлении есть пост в блоге Google, посвященном тестированию. В юнит-тестах не наблюдается такого нестабильного поведения. Они могут то проходить, то падать — причем без видимых изменений, исключительно из-за I/O. Можно ли убрать непредсказуемость? Нет, но можно свести её к минимуму.
Чтобы избавиться от непредсказуемости, делайте как можно меньше E2E-тестов. Пишите один E2E-тест на десять других, и лишь тогда, когда они действительно необходимы.
Пишем E2E-тесты
Перейдём к написанию E2E-тестов. Нам нужны две вещи: браузер и сервер для нашего фронтенд-кода.
Сперва взглянем на настройку веб-сервера.
Настройка веб-сервера в Mocha
Веб-сервер на Node? На ум сразу же приходит express, давайте посмотрим код:
В функции before мы создаем express-приложение, указываем ему папку dist и прописываем слушать порт 8080. В функции after мы «убиваем» сервер.
Папка dist — это то место, где мы храним наши JS-скрипты и куда копируем HTML- и CSS-файлы. Вы можете увидеть, что мы делаем это в сборочном скрипте npm в package.json :
Папка dist используется как в пользовательском окружении, так и в E2E-тестах. Это важно — запускать E2E-тесты нужно в средах, максимально похожих на «боевые».
Настройка браузера в Mocha
Для начала давайте посмотрим, как мы используем её, прежде чем начнём разбираться с настройками:
Это сложная штука. И я должен кое-что признать: этот код был написан кровью (о, и он работает только в Unix-системах). Он был написан при помощи Google, Stack Overflow и документации webdriver и сильно модифицирован методом научного тыка. Но он работает!
Теоретически вы можете просто скопипастить код в свои тесты, не разбираясь в нём, но давайте заглянем в него на секунду.
Почему мы делаем это в строках 11–15? Причины скрыты туманом опыта. Не стесняйтесь копипастить — никаких гарантий не прилагается, но я использовал этот код некоторое время, и проблем не возникало.
Приступим к тестам
Мы закончили настройку — пришло время взглянуть на код, который использует webdriver для управления браузером и тестирования нашего кода.
Разберём код по частям:
Пропустим установку, которую мы видели раньше, и перейдем к самой тестовой функции.
Код переходит к приложению и проверяет, что его название — «Calculator». Первую строку мы уже видели — мы открываем наше приложение с помощью драйвера. И не забываем дождаться окончания процесса.
Перейдём к строке 9. Здесь мы просим браузер вернуть нам заголовок (используем await для ответа, потому что это асинхронно), а в строке 10 мы проверяем, что заголовок title имеет корректное значение.
Поиск элементов
Дальше, к следующей части теста!
В строке 10 с помощью метода getText() мы получаем содержимое элемента и проверяем его. Помните, что нужно дожидаться ( await ) выполнения всех методов!
Пользовательский интерфейс
Настало время тестировать наше приложение — нажимать на цифры и операторы и проверять результат операций:
Выполнение всех тестов
Итак, у нас есть E2E-тесты и юнит-тесты, запустим их с помощью npm test :
Внедрение E2E-тестирования с Puppeteer и Jest
Хотим поделиться краткой историей о том, как мы на одном из проектов «Рексофт» пришли к написанию автотестов, и почему сделали акцент именно на e2e-тестах.
Речь пойдет о работе с порталом крупного федерального заказчика, работающего в сфере B2B и B2C, имеющего серьезный трафик из всех регионов. Сайт писал не «Рексофт». Ресурс попал к нам на поддержку какое-то время назад. Изначально проект содержал довольно много легаси кода, тестов не было, как и документации. Требовалось сделать редизайн по новым макетам, параллельно расширяя существующую функциональность. Обычная история.
В какой-то момент мы поняли, что ручное прокликивание интерфейса стало занимать очень много времени, и решили, что пришло время для автотестов.
Перед выбором подхода к автотестам классифицировали баги по типу: их большая часть касалась именно бизнес-логики (Javascript). Багов, связанных с кроссбраузерностью или вёрсткой, было не очень много.
Итак, цель была поставлена — автоматизировать проверку бизнес-логики, т.е. заполнение и отправку форм, работу слайдеров и т.д.
В качестве базового фреймворка для тестов был выбран Jest, а для имитации действий пользователя — Puppeteer. Последний выбрали благодаря тому, что он поддерживается Google и имеет отличную документацию. Нам было вполне достаточно тестов в одном браузере (Chrome) (хотя, есть инструменты, позволяющие с помощью Puppeteer запускать тесты и в других браузерах, например, Firefox и IE). Playwright тогда ещё не было, а Selenium, чисто субъективно, казался более сложным в развертывании.
Далее кратко опишу преимущества и недостатки e2e-тестов.
Недостатки e2e-тестов
Относительно высокая сложность написания. Нужно обладать определёнными навыками, чтобы написать компактный и легкочитаемый e2e-тест.
Проблема закопаться. Я точно знаю, что желание проверить всё и вся, может привести к написанию огромного количества избыточных тестов. Как побороть эту проблему? Не стоит пытаться протестировать абсолютно все возможные кейсы, достаточно сосредоточиться на основных.
Низкая скорость прохождения тестов (в сравнении с юнит-тестами). Довольно много времени тратится на запуск браузера, ожидание загрузки страницы, завершения анимаций и прочее. Для ускорения прохождения тестов потребуется свести к минимуму число пользовательских действий, а также число загрузок новых страниц.
Ускорить прохождение тестов можно, запуская их параллельно. В этом поможет Browser Context в Puppeteer.
Число параллельно запускаемых тестов в Jest регулируется флагом —maxWorkers.
«Хрупкость» e2e-тестов. Что я имею ввиду? Случай, когда тест падает без видимых на то причин, а при повторном запуске успешно выполняется, или же когда к падению теста приводит незначительное изменение в верстке. С хрупкостью тестов можно бороться с помощью автоматического перезапуска теста после падения. Помогут в этом раннер jest-circus и параметр retryTimes. Это практически полностью решает проблему “ложных” падений тестов.
Преимущества e2e-тестов
Гарантии. С e2e-тестами вы получаете определенные гарантии того, что система в целом работает корректно. Юниты такой гарантии не дают. Разумеется, это не значит, что вы получаете 100% гарантию того, что у вас работает абсолютно всё. Но вы будете уверены, что по крайней мере протестированные сценарии точно работают.
Снижение рабочей нагрузки. Без тестов разработчик вынужден думать — «как бы чего не сломать». Ведь не прокликивать же весь проект после очередного коммита с правками! С тестами вы узнаете о поломке еще до того, как код будет залит на стенд.
Ускорение разработки. Благодаря снижению количества багов и устранению ручных проверок интерфейса, серьезно экономится время. Причём e2e-тесты экономят не только ваше время, но и время тестировщиков (позволяя им заводить меньше багов, меньше коммуницировать, выясняя их детали и т. д.), время аналитиков (понятные тесты — отличная документация, отвечать на вопросы аналитиков вы будете намного быстрее).
Ускорение рефакторинга. При рефакторинге js, e2e-тесты не придется переписывать. Да и рефакторинг в вёрстке тоже редко приводит к их переписыванию.
Нет зависимости от кодовой базы и js-фреймворка. Вы можете написать e2e-тесты даже к легаси коду, что поможет быстрее его отрефакторить. При этом вы практически не зависите от js-фреймворка, т.к. в тестах оперируете только сущностями браузера.
Лайфхаки
1. Для ускорения написания первых тестов можно записывать действия пользователя с помощью Headless recorder или с помощью встроенных в Chrome инструментов.
2. Если требуется проверить несколько наборов данных в рамках одного кейса и руки тянутся написать for внутри теста, используйте jest-each. Эта библиотека позволит прогнать несколько наборов данных в одном кейсе, сохранив читаемость кода:
3. В случае возникновения ошибок, puppeteer не всегда корректно подсвечивает строку с ошибкой. Поэтому следует проверить код перед ошибочной строкой, часто ошибка кроется именно там.
4. Puppeteer позволяет запускать браузер с различными флагами, что иногда очень полезно (chrome://flags/). Ниже пример запуска браузера с отключенным флагом SameSite by default cookies
В качестве заключения
Написание e2e-тестов занимают около 5-10% от времени написания фичи. На фиксы багов уходило сильно больше времени, так что оно того стоило. Несмотря на ряд недостатков, e2e-тесты позволяют значительно ускорить процесс разработки и обрести уверенность в том, что основная функциональность системы работает.
Разумеется, при внедрении e2e-тестов для фронтенда необходимо учитывать специфику вашего проекта. Спасибо за внимание!
Как e2e автотесты на Selenide помогают QA-команде при частых релизах
Всем привет! Я Иван, старший инженер-тестировщик в КРОК. Уже 6 лет занимаюсь тестированием ПО. Из них 3 года внедряю автоматизацию тестирования на различных проектах — люблю всё автоматизировать. На рабочей машине много разных “батников” и bash-скриптов, которые призваны упрощать жизнь.
Недавно у нас стартовал проект по модернизации и импортозамещению системы электронного документооборота (СЭД) в одной крупной организации. Система состоит из основного приложения и двух десятков микросервисов, в основном — для построения отчётов и интеграции с другими подсистемами. Сейчас в проекте уже настроено больше 100 автотестов, и они сильно помогают при частых релизах, когда времени на регресс почти нет. Весь набор автотестов выполняется примерно за 25 минут, в среднем экономим до 3,5 часов ручной работы при каждом запуске. А запускаем мы их каждый день.
Дальше будет про то, как мы выбирали технологии и инструменты, какой каркас и подход к организации автотестов в итоге получился. И почему мы в КРОК решили тиражировать этот подход в других проектах, реализация которых основана на Content Management Framework (CMF) под СЭД. На базе CMF у нас есть комплексное решение для автоматизации процессов документооборота КСЭД 3.0. Конечно, отдельные решения по автотестам можно применять под любую СЭД.
Ещё расскажу про проблемы, и как мы их решали. Пост будет интересен и полезен, если в ваших автотестах необходимо подписывать документ электронной подписью (ЭП) в докер-образе браузера, проверять содержимое pdf файла, выполнять сравнение скриншотов или интегрироваться с одной из популярных Test Management System.
Что имели на входе
Много лет у заказчика была СЭД, которую мы же в КРОК делали на базе экосистемы Microsoft (.NET Framework, MS SQL Server, IIS, Active Directory). Но закон об импортозамещении ПО в госсекторе, ФЗ «О безопасности критической информационной инфраструктуры», плюс моральное устаревание существующей системы стали причиной решения о создании новой, уже на open source решениях.
Основной функционал новой СЭД реализуется в едином приложении. Для масштабирования запускается несколько экземпляров приложения, которые находятся за балансировщиком нагрузки. Из приложения выделено несколько подсистем, развёртываемых в качестве отдельных сервисов, — это даёт более гибкое масштабирование.
UI реализуется с использованием фреймворка Vue.JS. Бэкенд, как писал ранее, разрабатывается на собственном Content Management Framework (CMF) с реализованными процессами под СЭД. Основа для него — jXFW (CROC Java Extendable FrameWork). Зарегистрирован в Едином реестре российских программ для ЭВМ и баз данных (от 29 Марта 2018, регистрационный номер ПО: 4309). Про jXFW мой коллега писал отдельно вот здесь. Данные хранятся в БД PostgreSQL. Автоматизация бизнес-процессов выполнена при помощи Camunda. В качестве брокера сообщений используется RabbitMQ. Для наглядности, укрупненная физическая архитектура системы выглядит примерно так:
Почему решили делать автотесты
Проект нужно было сдать в короткие сроки, с очень частыми релизами. Мне было очевидно, что автоматизация тестирования должна нам помочь. Оставалось убедить в этом руководство.
Я сел и посчитал, сколько времени уйдёт на ручное тестирование базового функционала при каждом релизе, и сколько времени нужно для написания и поддержки автотестов. В итоге получилось, что в среднем на двадцатый прогон тесты окупятся и далее будут приносить экономическую выгоду. Учитывая, что в неделю мы выпускаем несколько релизов, то приблизительно уже через 1,5-2 месяца мы должны получить профит. Изначально таблица расчётов выглядела так:
Время написания автотестов
Ручное выполнение
набора тестов (за 1 раз)
Что такое сквозное тестирование e2e
Понятия B2B и B2C всем давно известны. А вот значение аббревиатуры E2E, как показывает практика, знают далеко не все. Если вы нашли себя в числе этих «не всех», предлагаем разбираться вместе.
Итак, E2E сокращение с английского «End-to-end»*.
*Стоит упомянуть о том, что в мире информационных технологий существует и другое значение аббревиатуры, также имеющее расшифровку «end-to-end», однако связанное со сквозной передачей данных. Говоря об IT решениях, важно знать контекст, чтобы не перепутать одно с другим.
В обиход введено несколько лет назад Джеймсом Славетом, партнером Greylock Partners, который является инвестором компаний Airbnb и Redfin.
И обозначает собственно направление бизнеса, когда некий товар/услуга/ценность предоставляемый некоторым количеством продавцов доносится до конечного потребителя с помощью специального софтверного продукта (web-площадки, приложения) агрегирующей первых со вторыми. Такая площадка и будет представлять E2E бизнес. Употребляя термин «ценность», имеем в виду то, что объектом обмена могут быть не только товар или услуга, но также и отношения между людьми (сайты знакомств, к примеру).
Теперь о главном, откуда же собственно берутся деньги? Путей несколько, вот они:
Обычно в разном процентном соотношении одновременно работают сразу несколько схем. Е2Е проекты воплощают идеал силиконовой долины, когда сравнительно небольшая группа людей создает массово востребованный продукт.
Несмотря на то, что сейчас принято говорить о Uber и Airbnb, как о флагманах E2E, все-таки само явление в бизнесе появилось гораздо раньше. Предлагаем вспомнить о том, что booking.com был основан почти за десятилетие до нашумевшего Uber.
Другой момент, что само понятие E2E, как течения в бизнесе, появилось гораздо позже, благодаря вышеупомянутому инвестору Airbnb.
Своим стремительным ростом E2E компании сильно обязаны росту и распространению смартфонов. Телефон – кнопка, с помощью которой можно управлять жизнью. Мы вызываем такси, заказываем еду, обмениваемся информацией, перекидываем деньги на счетах в банках, общаемся. Почти весь наш офлайн управляем в онлайн. Просто представьте, что Вам будет обиднее потерять кошелек или телефон?
Если несколько лет назад можно было говорить о стремительном росте E2E, и нарастающей популярности подобных сервисов, то сегодня мы уже можем смело говорить о захвате ими рынков. Вспомните, давно ли Вы ловили частника, чтобы доехать до дома? Уже растет поколение потребителей, которым неведомо слово «бомбила». У людей появляются мысли отказаться от личного автомобиля в пользу такси из соображений экономии, потому что цены на такси действительно резко упали, благодаря агрегаторам.
Специфика Е2Е такова, что успех – это бесперебойная работа приложения, правильный маркетинг и исключительная гибкость по отношению к клиенту. Возможность оперативно меняться под его запросы.
Это, безусловно, здорово для клиента, но хотелось бы все-таки посмотреть на это все с точки зрения сервиса для HR, где в едином пространстве подобного сервиса можно будет найти услуги по рекрутменту, обучении, оценке и пр.
Итак, первый очевидный вывод, на котором не буду останавливаться долго: разработчики, которых уже дефицит, будут востребованы еще больше. IT рекрутмент будет самой быстро оборачиваемой частью рынка человеческих ресурсов. Хорошие IT рекрутеры будут наиболее высокооплачиваемыми специалистами нашей отрасли.
А вот, что же будет с рынком подбора персонала? Логика и интуиция кричат примерно о следующем: сейчас в Москве более 1000 зарегистрированных кадровых агентств и несметное количество фрилансеров. Несомненно, есть крупные игроки, но большинство агентств очень маленькие. А вот теперь давайте представим, что появляется агрегатор, который собирает в себе все эти агентства с одной стороны и компании, готовые обратиться за помощью с другой. Теперь HR менеджеру или руководителю компании не надо тратить время на встречи с представителями агентств, чтобы понять экспертизу, не надо затевать скачки, заключая договора с 5 провайдерами одновременно. Он просто набирает в приложении отрасль, название вакансии, и программа выдает агентство, которое успешно закрывало похожий проект. Вот так, одним кликом.
Есть уже попытки создания подобных сервисов, но пока не такие успешные. Мы уверенны, что это вопрос времени и того, кто первый создаст надежный агрегатор и грамотно выведет его на рынок.
На этом поставим запятую, и вернемся к теме через несколько лет, а может и меньше. Ниже вкратце рассказываем о некоторых E2E компаниях.
«Однажды вечером, в 2008 году, в Париже во время снегопада Трэвис Каланик и Гэррет Кэмп не могли поймать такси. Тогда им и пришла в голову простая идея — нажал кнопку и поехал».
Так красиво историю о себе начинает сама компания.
А вот информация про компанию с сайта ХабраХабр.ру
В 2009 году они вместе с Калаником создали Ubercab — мобильное приложение, позволявшее одним кликом вызывать личного водителя. Тогда сервисом пользовались друзья в Сан-Франциско, мало кто относился к нему серьёзно. Когда Камп спросил Каланика, будет ли он заниматься им постоянно, тот ответил отрицательно — полностью посвящать себя такой авантюре было рискованно.
Год назад основателя Трэвиса Каланика обвинили в краже идеи и технологий. Якобы Кевин Халперн из Калифорнии создал прототип сервиса для заказа такси через мобильное приложение много лет назад. Предприниматель требовал возместить ущерб на сумму в один миллиард долларов.
Халперн утверждал, что свой прототип он разработал еще в 2002 году, в своей компании Celluride Wireless. Они познакомились с Калаником в 2006 году. Тогда Халперн и продемонстрировал ему свои наработки. Каланик якобы воспользовался ими для создания собственного проекта. Заслуживает внимания упоминание об их повторной встрече в 2008 году. Именно тогда он раскрыл Каланику детали проекта. А через год после этого был запущен сервис Uber. Представители компании убеждены, что претензии безосновательны.
О будущем Ubercab много спорили. Одни говорили, что сервис нужно сфокусировать на сегменте люкс, добавив функции заказа вертолётов и самолётов. Другие предлагали делать Ubercab массовым, позволяющим ездить на дорогих чёрных машинах дешевле, чем в целом по рынку. Так считал и Каланик. Он рассуждал: «Чем больше людей захотят этим пользоваться, тем больше водителей будет готово предоставить такие услуги. Конкуренция вырастет, стоимость снизится, а время подачи машины уменьшится».
Родители Трэвиса Каланика были первыми пассажирами Uber, запустившегося в Лос-Анджелесе.
В настоящий момент, кроме Убер, существуют несколько десятков более ли менее известных такси-сервисов такого рода, однако, несмотря на критику по определенным вопросам, Уберу удается удерживать одни из самых низких цен, что позволяет быть выше конкурентов. AirBnB
Еще одна всемирно известная компания AirBnB, (изначально AirBed&Breakfast — «надувной матрас и завтрак»).
Пользователи Airbnb имеют возможность сдавать путешественникам в аренду своё жильё целиком или частично. Сайт предоставляет платформу для установления контакта между хозяином и гостем, а также отвечает за обработку транзакций. Airbnb предлагает жильё в 65 000 городов 191 страны мира. С момента основания в августе 2008 года и до апреля 2017 года через сайт Airbnb нашли жильё более 150 млн человек. За свою деятельность Airbnb взимает определённый процент — с хозяев апартаментов 3 % от суммы бронирования, с арендатора — от 6 % до 12 % (по данным на апрель 2017 года).
Airbnb был основан в августе 2008 года в Сан-Франциско. Его основателями являются Брайан Чески, Джо Геббиа и Нейтан Блечарчик. Первоначальное финансирование было получено от бизнес-инкубатора Y Combinator. Позднее Greylock Partners, Sequoia Capital и Эштон Кутчер также инвестировали в компанию.
Кроме штаб-квартиры в Сан-Франциско, компания имеет 10 региональных офисов: в Барселоне, Берлине, Гамбурге, Копенгагене, Лондоне, Милане, Париже, Сан-Паулу, Сингапуре и Сиднее.
Перед Гран-при Канады компания стала спонсором команды Manor Marussia F1 Team.
Хочется сказать о ней, как о компании появившейся значительно раньше понятия E2E.
В 1996-м компания Microsoft запустила сайт для бронирования отелей и авиабилетов Expedia.com. Основатель корпорации Билл Гейтс впоследствии сказал, что предвидел: интернет-пользователи захотят самостоятельно, безо всяких посредников планировать и подготавливать путешествия.
В то же самое время в Голландии выпускник факультета технического администрирования Университета Твенте Герт-Ян Бруинсма обзванивал гостиницы в европейских городах и просил их прислать ему по обычной почте рекламные буклеты с фотографиями номеров. Отсканированные изображения он выкладывал на сайт Bookings.nl. Через несколько лет ресурс стал недосягаемым лидером онлайн-рынка туризма.
Сервис Omnipresenz задуман, как для вечно занятых людей, у которых нет времени путешествовать или посещать встречи в других городах мира, так и для тех личностей, кому физическое состояние не позволяет покорять новые страны, к примеру, для стариков или инвалидов. Ведь зачем ехать в Венецию, если вы можете связаться с человеком, уже находящимся в этом городе, и попросить его прогуляться вдоль каналов с онлайн-камерой на голове.
Вопрос равноценности онлайн и офлайн путешествий, безусловно, спорный, но факт в том, что сервис существует и существует спрос на него.
End-to-end тестирование микросервисов c Catcher
Добрый день! Я хотел бы представить новый инструмент для end-to-end тестирования микросервисов – Catcher
Зачем тестировать?
Зачем нужно e2e тестирование? Мартин Фаулер рекомендует избегать его в пользу более простых тестов.
Однако, чем выше находятся тесты — тем меньше переписывать. Юнит тесты переписываются почти полностью. На функциональные тесты также приходится тратить свое время в случае серьезного рефакторинга. End-to-end тесты же должны проверять бизнес логику, а она меняется реже всего.
К тому же, даже полное покрытие тестами всех микросервисов не гарантирует их корректного взаимодействия. Разработчики могут неправильно имплементировать протокол (ошибки в наименовании/типе данных).
Или реализовать новый функционал полагаясь на схему данных из документации, а на продуктовом окружении получить сюрприз в виде ошибок несоответствия схем: бардак в данных либо кто-то забыл обновить схему данных.
И тесты каждого из задействованных сервисов будут зеленые.
А зачем автоматическое тестирование?
Действительно. На моем предыдущем месте работы решили, что тратить время на разворачивание автоматических тестов это слишком долго, сложно и дорого. Система не большая (10-15 микросервисов с общей кафкой). CTO решил, что «тесты не важны, главное чтобы система работала». Тестировали вручную на нескольких окружениях.
Как это выглядело (общий процесс):
А теперь немного дегтя в эту бочку с шоколадом: на большинство тестов нужно было создавать пользователей, потому что переиспользовать существующих сложно.
Во-первых, из-за того, что система распределенная — у нескольких сервисов были свои базы данных, в которых лежала информация о пользователях.
Во-вторых, кафка использовалась для постоянного хранения данных. Т.е. даже если информацию удалить/изменить в базе данных, сервис при перезагрузке все-равно прочитает ее обратно.
Как выглядела регистрация нового тестового пользователя (приблизительно):
Супер, пользователь зарегистрирован! Теперь еще немного дегтя: для некоторых тестов нужно больше чем 1 тестовый пользователь. И иногда с первого раза тесты не проходят.
А как происходит проверка нового функционала и подтверждение со стороны бизнес-команды?
Все то же самое нужно повторить на следующем окружении.
Нужно ли говорить, что через некоторое время начинаешь ощущать себя мартышкой, которая только и делает что нажимает кнопки, регистрируя пользователей.
Еще у некоторых разработчиков (обычно у фронт-энда) были проблемы с подключением к кафке. И с багом в терминале при строке 80+ символов (не все знали про tmux).
Плюсы:
Минусы:
Как автоматизировать?
Если вы дочитали до сюда кивая головой и приговаривая: «да, отличный процесс, парни знают что делают», то дальше вам будет не интересно.
Самодельные e2e тесты бывают двух типов и зависят от того, какой из программистов был более свободен:
Звучит неплохо. Проблемы?
Да, такие тесты пишутся на том, что знает тот, кто их пишет. Обычно это скриптовые языки вроде руби или питон, которые позволяют быстро и просто написать подобного рода вещь. Однако, иногда можно наткнуться на ворох баш-скриптов, Си или что-то более экзотическое (я потратил неделю, переписывая велосипед на баш скриптах на питон, потому что скрипты уже были не расширяемыми и никто толком не знал как они работают и что тестируют).
Пример проекта здесь
Плюсы:
Минусы:
Есть что-нибудь готовое?
Конечно, достаточно посмотреть в сторону BDD. Есть Cucumber, есть Gauge.
Если кратко – разработчик описывает бизнес сценарий на специальном языке, после реализует шаги сценария в коде. Язык как правило человекочитаемый и предполагается что его будут читать/писать не только разработчики, но и менеджеры проектов.
Сценарии вместе с реализацией шагов также находятся в отдельном проекте и запускаются сторонними продуктами (Cucumber/Gauge/…).
Сценарий выглядит так:
Плюсы:
Минусы:
Ну и зачем тогда Catcher?
Разумеется, чтобы упростить процесс.
Разработчик пишет только сценарии в json/yaml, а Catcher их выполняет. Сценарий состоит из последовательно выполняемых шагов, например:
Catcher поддерживает jinja2 шаблоны, так что можно использовать переменные вместо зашитых значений в примере выше. Глобальные переменные можно хранить в инвентарных файлах (как в ансибле), подтягивать из окружения и регистрировать новые:
Дополнительно можно запускать проверочные шаги:
Также можно запускать одни скрипты из других скриптов, что отлично сказывается на чистоте и повторном использовании кода (включая запуск только части шагов через систему тегов, отложенный запуск и т.п. плюшки).
Вставка и использование скриптов могут решить проблему ожидания ресурса (ждать сервис, пока он стартует).
Помимо готовых встроенные шагов и дополнительного репозитория) есть возможность писать свои модули на питоне (просто наследуя ExternalStep) или на любом другом языке:
Сценарии помещаются в докер файл и запускается через CI.
Также этот образ может быть использован в Marathon/K8s для тестирования существующего окружения. На данный момент я работаю над бэкэндом (аналог AnsibleTower), чтобы сделать процесс тестирования еще проще и удобнее.
Плюсы:
Минусы:
Вместо заключения
Когда я писал этот инструмент, я просто хотел сократить время, которое я обычно трачу на тесты. Так получилось, что в каждой новой компании приходится писать (или переписывать) такую систему.
Однако инструмент получился гибче, чем я предполагал. Если кого-то заинтересует статья (или сам инструмент), я могу рассказать, как использовать Catcher для организации централизованных миграций и обновления системы микросервисов.
Как мне указали в комментариях, тема не раскрыта.
Попытаюсь указать здесь наиболее спорные тезисы.