Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Теперь WebDriver готов к работе – давайте напишем наш первый web-тест! Это будет простой поиск DuckDuckGo. DuckDuckGo – это поисковик, который не отслеживает пользовательские данные. Пользователи могут вводить запросы и получать ссылки на соответствующие сайты, как и в любой другой поисковой системе.
Автор: Джош Грант (Josh Grant) Оригинал статьи Перевод: Ольга Алифанова
В своей последней статье о прелестях Pytest я бы хотел немного изменить правила и поговорить о достоинствах такой библиотеки Python, как requests. Requests – несомненно, один из моих любимых программных продуктов. Как и говорится на его домашней страницы, Requests – это HTTP, сделанное для людей.
Недавно я провел свой первый трехдневный курс "Python для тестировщиков". Одна из тем, раскрытых в этом курсе – это создание тестов для REST API с использованием библиотеки запросов Python и фреймворка юнит-тестирования pytest.
В этой короткой серии статей я хочу исследовать библиотеку запросов Python и ее использование для создания тестов REST API. Это вторая часть серии, в которой мы рассмотрим создание тестов, управляемых через данные.
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Теперь, когда наш тест-проект создан, напишем несколько Web UI-тестов при помощи Selenium WebDriver!
Что такое WebDriver?
WebDriver – это программируемый интерфейс для взаимодействия с живыми веб-браузерами. Он позволяет тест-автоматизации открывать браузер, передавать клики, вводить символы, удалять текст, и чисто завершать работу с браузером. Интерфейс WebDriver рекомендован W3C. Самый популярный вариант реализации стандартов WebDriver – это Selenium WebDriver, бесплатный инструмент с открытым исходным кодом.
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.
