Недавно я провел свой первый трехдневный курс "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.
Автор: Джош Грант (Josh Grant) Оригинал статьи Перевод: Ольга Алифанова
Продолжая рассказывать о чудесных возможностях Pytest, я хочу немного поговорить о старой, но прекрасной фиче – о фикстурах.
Фикстуры – интересная и часто смущающая новичков тема в Pytest. Вначале они кажутся контринтуитивными и попросту неправильными, но как только вы поймете, как это работает, фикстуры станут неотъемлемой частью хорошего кода Pytest.
У вас наверняка было такое, когда вы и ваши друзья очень хотели посмотреть какой-нибудь фильм, а после жалели о том, что потратили на него время. Или, может быть, вы помните тот момент, когда ваша команда думала, что нашла «киллер фичу» и обнаруживала ее «подводные камни» только после выпуска продукта.
Хорошие идеи часто терпят неудачу на практике, и в мире тестирования хорошим примером этого может служить стратегия тестирования, построенная на автоматизации end-to-end тестов.
Тестировщики могут инвестировать свое время на написание многих типов автоматических тестов, включая модульные тесты, интеграционные тесты и end-2-end тесты, но эта стратегия в основном направлена на end-2-end тесты, которые проверяют продукт или услугу в целом. Как правило, эти тесты имитируют реальные пользовательские сценарии.
