Автор: Корина Пип (Corina Pip) Оригинал статьи Перевод: Ольга Алифанова
Все мы хорошо знакомы с концепцией случайным образом падающих автотестов. Это тесты, которые, несмотря на отсутствие изменений в тестируемой функции, или падают случайным образом на одном и том же шаге, или делают это каждый раз по-разному. Разбор результатов таких тестов может быть непростым делом, и некоторые команды предпочитают просто прогнать тест еще раз, если он упал. Но действительно ли это лучшее решение? Вот что думаю я.
Привет! Меня зовут Владимир, я разработчик команды продукта «Сервис персонализации» в SM Lab. В этом посте я хотел бы рассказать (а в комментариях — обсудить) один очень важный и полезный инструмент разработчика — юнит-тесты.
Вы наверняка уже много про них знаете, особенно если они составляют часть ваших рабочих обязанностей. Информации в сети много, проблема в том, что она не всегда полная и недостаточно хорошо структурирована.
Мой рассказ будет состоять из двух частей. В этой части я расскажу, что такое юнит-тестирование и для чего это нужно, что такое покрытие тестами, как оно считается и какие есть подводные камни, рассмотрю подходы к изоляции в юнит-тестах и виды зависимостей, а также вопросы, связанные с эффективностью юнит-тестов.
Эта статья для всех – кто слышал про них, но не видел, кто приступает к написанию юнит-тестов, и кто их пишет уже давно. Надеюсь, каждый из вас найдет что-то полезное для себя.
При подготовке материала очень помогла книга Владимира Хорикова (@vkhorikov ) «Принципы юнит-тестирования». Рекомендую ее всем, кто хочет еще глубже погрузиться в эту тему.
Это видео - фрагмент нового курса Арсения Батырова "Автоматизация тестирования REST API на Java". На видео мы пишем наш самый первый API-тест на языке Java, используя одну из самых популярных библиотек для создания http-запросов - REST-assured. Вы можете убедиться сами, что это просто и почти любой может научиться этому.
Для прохождения курса не нужны никакие предварительные знания о работе с HTTP и API. Мы всему научим. Однако, нужны базовые знания любого языка программирования:
Работа с циклами (for, while) и условиями (if)
Работа с функциями - входные параметры, return
Основы ООП - что такое классы и объекты классов
Курс “Автоматизация тестирования API на Java” специально создан для быстрого погружения в навыки, необходимые тестировщику для успешного старта карьеры в автоматизации. Да и для ручного тестировщика понимание внутреннего устройства API и возможность быстро проверить свои гипотезы простым скриптом будут значительными плюсами в работе.
Приходите на наш курс и научитесь писать API-тесты на самом популярном языке программирования в автоматизации.
Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова
Вместо того, чтобы кликать при логине, можно авторизоваться программно и появиться в приложении авторизованным пользователем. В этой статье мы разберем этот процесс. Объяснения можно найти и в документации Cypress, однако если вы хотите узнать больше о всяких тонкостях, продолжайте чтение.
Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова
Недавно я разбирался с конфигурацией Cypress. Я обнаружил, что особенно трудно настраивать разные окружения, особенно для новичков. В этой статье я разобью конфигурацию на последовательность небольших шагов, и это поможет вам ориентироваться в теме.
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
В предыдущих статьях серии о тестировании ориентированных на потребителя контрактов и Pact мы обсуждали CDCT, разобрались, как использовать Pact для поддержки CDCT, как автоматизировать процесс и сделать его частью процессов CI/CD, и посмотрели, что будет, когда на стороне потребителя меняются ожидания.
В шестой и последней статье мы посмотрим, как добавить в процесс CDCT новый сервис, и как это можно упростить при помощи подхода, который называется двусторонне направленным тестированием контрактов.
Предупреждение:двусторонне направленное тестирование контрактов существует только в Pactflow и недоступно в OSS Pact Broker.
Автор: Теодор Жеррад (Theodore Gerrad) Оригинал статьи Перевод: Ольга Алифанова
Если вы интересуетесь тест-автоматизацией, то в какой-то момент зададитесь одним (или всеми) из следующих вопросов – что такое Page Object Model (POM)? Важна ли тест-автоматизация? Надо ли этому учиться? Сколько времени это обучение займет? Если вы похожи на меня – а вы, скорее всего, похожи – то вы впадете в панику, быстро и последовательно спрашивая себя обо всем этом. Хоть я и не эксперт (пока что), я могу предложить свой взгляд на эту проблему. Хоть я и не могу явно ответить на все эти вопросы, я хотел бы поделиться рядом мыслей в этой статье.
Привет, я Black из Scalable, QA Lead в команде бэкенда по разработке биржевого ядра. Так как уже долгое время занимаюсь развитием высоконагруженной платформы, решил написать о том, как нам удалось поставить QA-процесс с 20 000 тест-кейсов, создать гибкую инфраструктуру для автоматизированного тестирования в нескольких типах API, включая асинхронные бинарные протоколы, и пройти путь разработки от отладочных утилит до специализированных тестовых фреймворков для интеграционного и компонентного тестирования.
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
В предыдущей статье мы остановились на том, что у нас все в порядке с интеграционным тестированием: провайдер Address способен удовлетворить ожидания потребителей Customer и Order. Затем мы успешно справились с автоматизацией генерации контрактов и их публикации. Мы также автоматизировали их загрузку, проверку и публикацию результатов верификации на стороне провайдера.
Однако, как все мы знаем, системы постоянно меняются, и в них часто добавляются новые требования и функции. В этой статье мы рассмотрим ситуацию, когда на стороне потребителя внедряются два различных требования, а затем разберемся, как это повлияет на результаты верификации со стороны провайдера и предположим, как справляться с проблемами интеграции в ходе тестирования контрактов.
Часто слышу мнение, что unit-тесты не нужны для мобильной разработки: в приложении должно быть минимум логики, основная работа с UI, а его сложно тестировать, да ещё и тесты отнимают время, которое можно было бы потратить на написание фич.
За этим мнением скрывается простая правда — люди, которые так говорят, не умеют писать тесты. Не умеют писать их быстро; писать там, где нужно; писать так, чтобы была ощутимая польза для бизнеса. Я тоже был таким — понимал, что тесты нужны, но не понимал какие, где и как их писать.
Рассказываю, что поменялось спустя 2 года и 4 тысячи тестов.
