Работа по TDD имеет очевидные преимущества: у разработчика всегда есть чётко описанная в виде теста цель, и он сразу узнает, когда она будет достигнута.
Тем не менее, есть и некоторые издержки: необходимо постоянно запускать один и тот же тест при изменениях в нем или в соответствующем классе, чтобы не пропустить тот самый момент истины. Вроде бы не такая уж и большая проблема, но постоянное переключение в консоль для проверки сделанных изменений на работоспособность, да и вообще помнить о необходимости этих манипуляций — лишнее рассеивание внимания.

Далее о том, как все это дело автоматизировать.

Привет Хабра!

Я не буду предлагать вам очередной модный фреймворк для тестов, а просто покажу подход к тестам и документации, который использую в проектах, разрабатываемых в i-Free. Возможно, вам понравится, и вы начнете организовывать проекты таким же образом или укажите мне на явные проблеммы.

Многие веб-разработчики не любят писать тесты, и я не исключение. Но тесты уменьшают количество багов и если ваше приложение становится все больше и больше, от тестов вам не уйти. К тому же в мелких компаниях я часто встречал джуниоров, которые вообще предпочитают писать код в текстовых редакторах (это увеличивает количество ошибок, т.к. редакторы не проверяют код). Как же начать потихоньку использовать тесты без боли и страданий?! Выход есть — подключить автотесты.

Суть поста на картинке слева. Это то, чего мне раньше не хватало в повседневной работе. Хотелось иметь инструмент, которым можно очень просто потыкать в код и сделать общее заключение о его живучести и пригодности.

Введение

Когда несколько лет назад я написал свой первый автотест, он выглядел следующим образом. В цикле 100 раз доставал из базы случайного пользователя, проводил над ним требуемую операцию и проверял, что результат меня устраивает. Это казалось достаточно логичным: не могу же я проводить тест на одном пользователе, этого недостаточно, это ничего не докажет.

С тех пор прошло значительное время, я успел поработать над несколькими разными проектами на разных языках и даже сменить команду. Сегодня я могу с уверенностью сказать: вы не должны использовать случайность в своих автотестах, кроме случаев, которые будут оговорены отдельно. И я расскажу почему.

Довольно часто среди начинающих (и даже не очень) тестировщиков приходится слышать: «вот если бы я умел писать автотесты, я бы…». Как правило этим «если бы» ребята и ограничиваются. На вопрос: «А почему не учишься писать?» чаще всего отвечают: «Программирование это не мое». Действительно, тем для кого программирование темный лес, погрузиться в мир автотестов довольно затруднительно, ведь скрипт сам себя не напишет. В этой статье я хотел бы поговорить о том, как из ручного тестировщика стать крутым автотестером.

Эта статья является продолжением SpiderTest: Автотесты своими руками. Однако, первая часть обзора на это приложение была больше ориентирована на десктопный интерфейс. В этой же хотелось бы поговорить об экзотике: связи тестов с CI-server’ом и GitHub.
Может возникнуть вопрос: «Зачем вообще все это нужно? Мы написали тест, прогнали его в нужных браузерах и нам достаточно» и в целом он довольно обоснованный! Действительно, для обычного тестирования, запуска автотестов из самого приложения SpiderTest в большинстве случаев бывает достаточно. Но что делать, если мы хотим запустить тесты в IE9-11, Opera, FireFox и Google Chrome разных версий? На одной машине это сделать невозможно, а создавать кучу виртуальных машин и запускать по очереди в каждой утомительно (и вообще это костыль).
А если мы хотим провести дымовое тестирование? Или хотим запускать тесты не только в разных браузерах, но и в разных операционных системах (Windows OS, Linux OS)?
Самый оптимальный ответ на поставленные выше вопросы – использовать сервер непрерывной интеграции. В этой статье я рассмотрю настройку SpiderTest и Jenkins. Справедливости ради стоит сказать, что запускать тесты можно и на bamboo, и на teamcity, но Jenkins прост и бесплатен, поэтому рассмотрим его.

Привет, Хабр! Сегодня я хочу рассказать, как мы построили с нуля гибкую и расширяемую систему для выполнения автотестов на Android-смартфонах. Сейчас у нас используется около 60 устройств для регрессионного тестирования мобильного приложения Почты Mail.Ru. В среднем они тестируют около 20 сборок приложения ежедневно. Для каждой сборки выполняется около 600 UI-тестов и более 3500 unit-тестов.

Автотесты доступны круглосуточно — они экономят очень много времени тестировщиков и позволяют нам выпускать качественное приложение. Без них мы бы тестировали каждую сборку 36 часов (с учетом ожидания) или примерно 13 часов без ожидания. Вместе со сборкой, актуализацией переводов, при рабочей загрузке агентов с автотестами тестирование в среднем занимает 1.5 часа, что ежедневно позволяет нам экономить недели работы тестировщиков.

Мы рассмотрим, как всё делать с самого начала тем, кто занимается написанием автотестов, а не инфраструктурой: начиная от покупки телефона, его перепрошивки и заканчивая созданием docker-контейнеров, внутри которых будет доступен телефон для автотестов.

Последнее время большое внимание в Программе «Единая Фронтальная Система» (ЕФС) уделяется автоматизации тестовых сценариев. Причины объективны и связаны с повышением уровня зрелости отдельных подсистем Программы и объемом регрессионного тестирования.

Постоянный рост объема функционала приводит к лавинообразному росту количества автотестов, а вместе с этим растет время на анализ результатов прогонов и поиск причин ошибок. О том, как мы сократили время и ушли от ручного разбора логов, читайте под катом.

Привет, Хабр! Напоминаем, что осталось всего три дня, чтобы успеть записаться на QIWI SERVER PARTY 2.0, который мы проведем в четверг, 15 марта.

Адрес тот же – г. Москва, Ул. Ленинская Слобода, 26с11 Loft#3, начинаем в 17.00 (спикеры выступают с 18 до 21).

Бесплатная регистрация доступна по ссылке, а под катом мы расскажем немного подробнее о том, какие доклады ждут вас в четверг.

Представьте, вы за два дня полностью реализовали новую фичу. Код написан, он работает и все классно. Ваш менеджер говорит, что можно сразу в релиз. «А как же тесты?» — воскликнет какой-нибудь дотошный коллега. «А зачем?» — ответите вы в один голос с менеджером. Зачем нам писать тесты? Как объяснять их необходимость другим? Зачем вовлекать тестировщиков, аналитиков и других участников? В этом посте я расскажу, как объяснить пользу тестов любому участнику проекта, а также зачем стоит тесты автоматизировать. И подкрепим все это серьезными исследованиями.