Публикую перевод моей статьи из блога ГитЛаба про то как начать использовать CI. Остальные переводы гитлабовских постов можно найти в блоге компании Softmart.
Представим на секунду, что вы не знаете ничего о концепции непрерывной интеграции (Continuous Integration — CI) и для чего она нужна. Или вы всё это забыли. В любом случае, начнем с основ.
Представьте, что вы работаете над проектом, в котором вся кодовая база состоит из двух текстовых файлов. Более того, очень важно, чтобы при конкатенации этих файлов в результате всегда получалась фраза "Hello world." Если это условие не выполняется, вся команда лишается месячной зарплаты. Да, все настолько серьезно.
Это третья статья об использовании Scala в тестировании. Сегодня будут рассмотрены примеры использования Apache Camel для создания тестовых заглушек, а также компонентов информационной системы.
Часто возникает необходимость эмулировать работу какой-либо части системы для интеграционного тестирования, сделать заглушку или написать простой компонент интеграции. Это может быть веб-сервис, возвращающий нужные ответы, тест, наполняющий базу данных, приложение, которое считывает сообщение из очереди и возвращает результат обработки, генератор файлов и другие компоненты.
Для разовой проверки интеграции мы бы использовали простое Java или Scala приложение, сценарий Apache JMeter или SoapUI. Но нам нужна система, которая постоянно работает, отвечает на запросы и не требует действий со стороны тестировщика — запустил и забыл. Для решения такой задачи мы можем создать приложение, основанное на фреймворке Apache Сamel.
Перевод руководства Samuele Zaza. Текст оригинальной статьи можно найти здесь.
Я до сих пор помню восторг от возможности наконец-то писать бекэнд большого проекта на node и я уверен, что многие разделяют мои чувства.
А что дальше? Мы должны быть уверены, что наше приложение ведет себя так, как мы того ожидаем. Один из самых распространенных способов достичь этого — тесты. Тестирование — это безумно полезная вещь, когда мы добавляем новую фичу в приложение: наличие уже установленного и настроенного тестового окружения, которое может быть запущено одной командой, помогает понять, в каком месте новая фига породит новые баги.
Мы с вами находимся в ситуации, когда на глобальных рынках представлены тысячи различных смартфонов под сотнями брендов. 
Привет, читатель! Если доводилось писать Selenuim-тесты чуть сложнее чем на пару полей ввода и одну кнопку, то эта статья может пригодиться.
Наверняка знакомо чувство неправильности происходящего, когда внезапно отказывался работать тест-кейс длиной в пару минут, вынуждая тыкаться вслепую, чтобы найти поломавшийся css- или xpath-селектор в сложном Single Page Application, раз за разом запуская этот медленный сценарий, только чтобы дождаться вывода лога в консоль. Оказывается, можно писать Selenium-тесты с комфортом!
Про Selenium. Когда-то это был просто плагин для FireFox. Нажимаешь кнопочку "запись", и начинаешь дергать интерфейсы тестируемого сайта (формочки, ссылки). Практически без знания программирования, полученный сценарий можно править, подставляя нужные значения проверок. Всё — тест готов! Запускай каждый раз после деплоя, и проверяй, чего сдвинул локтем. Потом в Selenium добавили API для разных языков. В частности есть и для JAVA. Через API можно делать тоже самое: запускать браузер с требуемым сайтом, проверять переданные значения в формах, ходить по ссылкам и т.д. Беда в том, что скрипт выполняется медленно. Чтобы тестировать тесты, надо перезапускать сценарий, а это форменная пытка. Clojure (поверх JAVA) позволяет выполнять куски кода в работающей программе посредством REPL прямо в редакторе!
React мы в Voximplant любим и ценим. Вовсе не из-за хайпа (полторы тысячи твитов о новом SDK просто потому, что это React Native) а потому, что фреймворк действительно удобный. Простое дробление интерфейса на маленькие изолированные кусочки – это то, чего так не хватало и Jade/Pug, и Web Components, и даже Angular. 
В большинстве популярных языков программирования и экосистем с зависимостями все плохо. Как правило, создатели нового языка программирования уделяют этому не очень много внимания: просто потому, что в новом языке еще нет сотен тысяч библиотек для разных архитектур и версий, нетривиальным образом зависящих друг от друга. А когда эти сотни тысяч библиотек появляются – уже поздно что-нибудь менять.
В нашей небольшой, но очень динамично развивающейся компании каждый день тестируется больше сотни задач. Все они проверяются как в тестовом окружении, так и в окружениях, более приближенных к реальному. Подавляющее большинство задач, связанных с web, проверяется автотестами, которых у нас много.
Примерно полгода назад тестов и задач стало столько, что наша маленькая ферма с Selenium в час пик стала буквально «захлебываться» от запросов на новую сессию Firefox или Chrome. Выглядело это примерно так: на Selenium grid образуется очередь из сессий, которые ждут свободный браузер. Пользователи продолжают запускать автотесты, и эта очередь продолжает расти, но браузеры заняты старыми задачами и сессии «отваливаются» с таймаутом.
Представим, что вы разработчик на JavaScript, Ruby, Python или PHP. Ваш язык программирования не ищет ошибок во время компиляции. Собственно, у него компиляции, как таковой, нету. Если вы допустите синтаксическую ошибку, вы, конечно, о ней узнаете. Когда запустите программу. 
Появилась потребность определять пол клиентов в базе и автоматически склонять ФИО для интернет-магазина. Специфика магазина – подарки и доставка цветов с поздравлениями.
Магазин принимает информацию о пользователях через форму быстрого заказа. Есть и обычная корзина, но многие пользуются именно быстрым заказом – там можно заполнить только телефон и сразу же перейти к оплате. Клиенты пользуются возможностью и часто вообще не указывают имя. Делать поля для ФИО обязательными бессмысленно – вписывать мусор вместо данных не запретить. Также как не запретить неправильно писать собственное имя.
Между тем правильное обращение к клиенту необходимо, иначе возможны казусы:
