CI (Continuous Integration) — в дословном переводе «непрерывная интеграция». Имеется в виду интеграция отдельных кусочков кода приложения между собой. Чем чаще мы собираем код воедино и проверяем:
Собирается ли он?
Проходят ли автотесты?
Тем лучше! CI позволяет делать такие проверки автоматически. Он используется в продвинутых командах разработки, которые пишут не только код, но и автотесты. Его спрашивают на собеседованиях — хотя бы понимание того, что это такое. Да, даже у тестировщиков.
Поэтому я расскажу в статье о том, что это такое. Как CI устроен и чем он пригодится вашему проекту. Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.
Автор: Хиллари Уивер-Робб (Hillary Weaver-Robb) Оригинал статьи Перевод: Ольга Алифанова
Я хотела провести рефакторинг некоторых примеров своих тестов, используя RestSharp и NUnit (например, тестов из этих статей). Для разовых акций это отличные примеры API-тестов, но когда вы их объединяете, то получаете неподдерживаемую свалку, нарушающую множество принципов разработки ПО. Если тест-код не соответствует тем же принципам и практикам, что и код приложения – на него легко махнуть рукой как на "ненастоящий код", но это тоже код, и он важен!
Сделать это довольно легко, потому что в Postman-е есть
документация с примерами. Более того, эти примеры можно найти в самом инструменте на вкладке «Tests», они называются «Snippets».
Вот только если вы не знакомы с языками программирования, получившийся тест будет из разряда «Оу, магия!». А что, если вы хотите подкорректировать тест? Поменять под себя? Какую часть можно трогать, а какую оставить как есть?
В этом видео я возьму пример из сниппетов Postman-а, и подробно объясню, что означает каждая его часть. Теперь редактировать будет не страшно!
Я довольно давно и много занимаюсь автоматизацией тестирования. И не понаслышке знаю, какую боль иногда доставляют новые версии чего угодно. Обновили XCode, вышла новая Selenium, придумали новый браузер (особое спасибо Microsoft за Edge и его драйвер), зачем-то вот вам еще один язык программирования… Все это автоматизатора приводит исключительно в радость от осознания собственной значимости. Ведь только он теперь способен запустить тесты на всем этом.
Менее опытные ребята, кто только постигают все азы и таинства работы с тестами, почему-то радость не испытывают. На нашем курсе по автоматизации ученики часто спрашивают про то, как работать с новыми версиями тех или иных составляющих стека. Об этом сегодня я и решил рассказать. Кому интересно — добро пожаловать под кат.
Автор: Мэри Дрейк (Marie Drake) Оригинал статьи Перевод: Ольга Алифанова
На этой неделе я помогала коллегам переносить существующие тесты WebdriverIO в Cypress. Если вы хотите знать, что такое Cypress, и чем он отличается от Selenium – посмотрите этот вебинар от Гила Тайара. Перенося некоторые тесты, я вспомнила, что существующий тест-набор использовал теги Cucumber для фильтрации того, какие тесты в каких окружениях прогоняются. Фильтрация тестов – полезная для нас фича, потому что на проде мы прогоняем только часть наших тестов. В имеющемся у нас сейчас фреймворке Cypress мы решили пользоваться стандартным подходом – писать тесты с использованием Mocha в качестве прогонщика, а не Cucumber. У Mocha есть способ фильтрации тестов с использованием паттерна –grep, но он сейчас не поддерживается в Cypress, и о его внедрении просят пользователи. Мне не очень-то хотелось использовать плагин Cypress Cucumber исключительно для использования функции тегов, поэтому я решила внедрить простенький обходной путь, который планирую предложить коллегам, пока мы ждем внедрения фичи от Cypress.
Автор: Джош Грант (Josh Grant) Оригинал статьи Перевод: Ольга Алифанова
Продолжая рассказывать о чудесных возможностях Pytest, я хочу немного поговорить о старой, но прекрасной фиче – о фикстурах.
Фикстуры – интересная и часто смущающая новичков тема в Pytest. Вначале они кажутся контринтуитивными и попросту неправильными, но как только вы поймете, как это работает, фикстуры станут неотъемлемой частью хорошего кода Pytest.
У вас наверняка было такое, когда вы и ваши друзья очень хотели посмотреть какой-нибудь фильм, а после жалели о том, что потратили на него время. Или, может быть, вы помните тот момент, когда ваша команда думала, что нашла «киллер фичу» и обнаруживала ее «подводные камни» только после выпуска продукта.
Хорошие идеи часто терпят неудачу на практике, и в мире тестирования хорошим примером этого может служить стратегия тестирования, построенная на автоматизации end-to-end тестов.
Тестировщики могут инвестировать свое время на написание многих типов автоматических тестов, включая модульные тесты, интеграционные тесты и end-2-end тесты, но эта стратегия в основном направлена на end-2-end тесты, которые проверяют продукт или услугу в целом. Как правило, эти тесты имитируют реальные пользовательские сценарии.
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Сталкивались ли вы с багами в веб-приложениях? Еще бы, все с ними встречались. Баги плохо выглядят, портят пользователю впечатление, и снижают ценность веб-приложения. Серьезные баги могут повлечь за собой большие издержки для бизнеса и повредить репутации компании.
Как предотвратить проникновение багов к пользователям? Лучший способ поймать баги – протестировать веб-приложение. Однако Web UI-тестирование может быть непростой задачей. Оно требует больше усилий, нежели юнит-тестирование, и славится своей нестабильностью.
Не бойтесь! Это пособие сделает тестирование Web UI простым занятием. Мы создадим простое, но устойчивое тест-решение для Web UI, используя Python, pytest, и Selenium WebDriver. Мы изучим стратегии хорошего тест-дизайна, а также паттерны хорошего кода автоматизации. К концу этого руководства вы будете владеть тест-автоматизацией веб-приложений! Ваш тест-проект на Python может также стать основой для ваших собственных кейсов.
Давайте представим себе гипотетическую ситауацию (в которую мы регулярно, вляпываемся). Вас назначили на проект «запилить» автоматизацию. Вам дают огромный тест план с большим количеством (тысячи их!) «ручных» тестов, и говорят что надо что-то сделать, и вотпрямщас. А еще, чтоб быстро и стабильно.
Писать Unit тесты, или даже думать о TDD — уже поздно, код продукта давным-давно написан. Ваше слово, товарищ автотестер!
К счастью, есть небольшой трюк, который позволит и coverage повысить, и сделать тесты стабильными и быстрыми — Subcutaneous tests («подкожные тесты»), но обо всем по порядку.
