Зачастую перед QA-инженером стоит задача покрытия функциональности автотестами, при этом без избыточных проверок, по правильной пирамиде. Но, прежде чем начать покрывать бизнес-логику, стоит понять, а что, вообще, можно покрыть на unit-тестах.
Автор: Пол Гриззаффи (Paul Grizzaffi) Оригинал статьи Перевод: Ольга Алифанова
Ранее я писал о концепции мягких ассертов. Процитирую себя: "Мягкий ассерт – это ассерт, результат которого записывается, но не останавливает выполнение тестового сценария на этой точке. Результаты всех мягких ассертов оцениваются в указанный автором тест-сценария момент, как правило, в конце; если какое-либо условие мягкого ассерта валидируется как ложь, мягкий ассерт сообщает о провале в результате, и тест-сценарий, как правило, отмечается как проваленный". Если вы пропустили предыдущую статью, прочитайте про концепцию мягких ассертов.
Привет! Меня зовут Алёна Луцик, я QA-инженер в команде Авито. За время работы я много раз убеждалась, что разработчик и тестировщик смотрят на код по-разному.
Зачастую перед тестировщиком стоит задача покрытия функциональности автотестами без избыточных проверок, с соблюдением пропорций пирамиды. Но прежде, чем начать покрывать бизнес-логику, стоит понять, что вообще можно покрыть на уровне unit-тестов.
В статье я расскажу о шагах, которые помогут прийти к взаимопониманию с коллегами-разработчиками.
Примеры будут приведены в рамках микросервисной архитектуры на языке Golang.
В последнее время все чаще слышу от коллег из других организаций о курсе на автоматизацию. Чаще всего это выражается в обучении за счет компании всех желающих мануальных тестировщиков автотестированию, т. е. стеку технологий для написания и поддержания автотестов. Помимо языка программирования (чаще Python или Java) изучают Git, Selenium или его аналоги, Jenkins и внутренние регламенты работы с автотестами. В нашей компании так же взяли курс на автоматизацию, в связи с чем возник вопрос — а что же будет с мануальными тестировщиками, откажутся ли от них совсем или будут стремиться сократить их количество?
На данный момент прямых ответов от руководств компаний нет, звучат стандартные фразы, вроде «Пока все остается как есть». Но есть ли профит от доучивания ручных тестировщиков до автотестера, и куда уведет мечта автоматизировать все процессы в тестировании? Расскажу на своем опыте.
Привет! А вот и вторая часть поста про принципы юнит-тестирования. Если в первой мы обсудили влияние тестов на разрабатываемые продукты и познакомились с теорией юнит-тестирования, то в этой обсудим некоторые практические моменты. Внутри поста — структура юнит-тестов, стили юнит-тестов, принципы рефакторинга, полезные советы для того, чтобы ваши юнит-тесты были эффективными и читаемыми, а также некоторые антипаттерны при написании тестов.
Ну и, конечно же, список источников, где можно получить дополнительную полезную информацию. В общем, начнём.
Автор: Корина Пип (Corina Pip) Оригинал статьи Перевод: Ольга Алифанова
Все мы хорошо знакомы с концепцией случайным образом падающих автотестов. Это тесты, которые, несмотря на отсутствие изменений в тестируемой функции, или падают случайным образом на одном и том же шаге, или делают это каждый раз по-разному. Разбор результатов таких тестов может быть непростым делом, и некоторые команды предпочитают просто прогнать тест еще раз, если он упал. Но действительно ли это лучшее решение? Вот что думаю я.
Привет! Меня зовут Владимир, я разработчик команды продукта «Сервис персонализации» в SM Lab. В этом посте я хотел бы рассказать (а в комментариях — обсудить) один очень важный и полезный инструмент разработчика — юнит-тесты.
Вы наверняка уже много про них знаете, особенно если они составляют часть ваших рабочих обязанностей. Информации в сети много, проблема в том, что она не всегда полная и недостаточно хорошо структурирована.
Мой рассказ будет состоять из двух частей. В этой части я расскажу, что такое юнит-тестирование и для чего это нужно, что такое покрытие тестами, как оно считается и какие есть подводные камни, рассмотрю подходы к изоляции в юнит-тестах и виды зависимостей, а также вопросы, связанные с эффективностью юнит-тестов.
Эта статья для всех – кто слышал про них, но не видел, кто приступает к написанию юнит-тестов, и кто их пишет уже давно. Надеюсь, каждый из вас найдет что-то полезное для себя.
При подготовке материала очень помогла книга Владимира Хорикова (@vkhorikov ) «Принципы юнит-тестирования». Рекомендую ее всем, кто хочет еще глубже погрузиться в эту тему.
Это видео - фрагмент нового курса Арсения Батырова "Автоматизация тестирования REST API на Java". На видео мы пишем наш самый первый API-тест на языке Java, используя одну из самых популярных библиотек для создания http-запросов - REST-assured. Вы можете убедиться сами, что это просто и почти любой может научиться этому.
Для прохождения курса не нужны никакие предварительные знания о работе с HTTP и API. Мы всему научим. Однако, нужны базовые знания любого языка программирования:
Работа с циклами (for, while) и условиями (if)
Работа с функциями - входные параметры, return
Основы ООП - что такое классы и объекты классов
Курс “Автоматизация тестирования API на Java” специально создан для быстрого погружения в навыки, необходимые тестировщику для успешного старта карьеры в автоматизации. Да и для ручного тестировщика понимание внутреннего устройства API и возможность быстро проверить свои гипотезы простым скриптом будут значительными плюсами в работе.
Приходите на наш курс и научитесь писать API-тесты на самом популярном языке программирования в автоматизации.
