Agile-разработка программного обеспечения — это практика обеспечения непрерывной обратной связи для итеративного совершенствования ПО в соответствии с основными ценностями, изложенными в Agile-манифесте.
Agile-методологии ориентированы на непрерывное планирование, тестирование и интеграцию ПО, предоставляя сотрудникам возможность взаимодействовать и принимать решения быстро и эффективно. Таким образом, команды могут своевременно адаптироваться к меняющейся ситуации, получая обратную связь и информацию в процессе работы.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Содержание:
- Как использовать mock-сервисы в agile-разработке
- Создание моков в Postman
- Динамическое обновление моков
Как использовать mock-сервисы в agile-разработке
Задержки в разработке фронтенда или бэкенда затрудняют эффективную работу зависимых команд. В рамках agile-разработки такие задержки могут быть устранены с помощью имитационных или мок-сервисов.
Сервис Postman даёт возможность имитировать ответ сервера, что позволяет команде тестировщиков разрабатывать или писать тесты для ещё незавершённого или нестабильного ПО. Имитационная конечная точка, работающая на серверах Postman, будет возвращать сохранённый ответ, воспроизводя работу реального сервиса.
По сути, мок-сервисы помогают представить работу реального сервиса ещё до его создания.
Непрерывное планирование
Mock-сервисы используются на самых ранних стадиях планирования для создания прототипа новой идеи. Например, фронтенд-разработчик создаёт моки для команды разработчиков платформы, чтобы показать, какой код ответа сервера необходим для поддержки пользовательского интерфейса, над которым ведётся работа.
Этот прототип даёт старт процессу планирования и не требует больших технических затрат. Создать моки можно несколькими щелчками мыши, не используя интегрированную среду разработки (Integrated Development Environment, IDE) и не разбираясь в существующем коде.
Непрерывная разработка
После согласования требований моки будут использоваться для определения критерия готовности (Definition of Done, DoD) — показателя, который используется для оценки завершённости ПО. Моки могут быть включены в документацию продукта, над которым команда начинает работать. Команда использует моки, чтобы визуализировать ожидаемый ответ сервера и начать параллельную разработку и тестирование.
При использовании каскадной модели тестирование начинается после завершения разработки.
Agile-разработка, напротив, позволяет тестировщикам участвовать на всех этапах работы над ПО. Эмулируя разрабатываемый или недоступный сервис, тестировщик может приступить к написанию модульных тестов для планируемого API сразу же после согласования спецификаций.
Непрерывное тестирование
В современной экосистеме, в которой важными являются как внутренние, так и внешние сервисы, зависимости могут стать намного сложнее. Автоматизации сценариев тестирования, основанная на mock-сервисах, особенно полезна для обнаружения дефектов на ранних этапах и обеспечения быстрой обратной связи.
При тестировании частей приложения, взаимодействующими с внутренними сервисами, модульные тесты могут быть написаны и выполнены на основе моков. Тестировщики также могут упростить интеграционное тестирование благодаря имитации внешних зависимостей.
Знание того, каким будет код ответа сервера, позволяет тестировщику изолировать тестируемую систему. Например, при тестировании системы верификации, можно имитировать ответ стороннего сервиса, зная, что любые сбои, обнаруженные в результате тестирования, должны быть отнесены к тестируемой системе.
Общим для всех этапов agile-разработки является то, что команды используют mock-сервисы для разделения процесса разработки, позволяя сотрудникам работать параллельно.
Создание моков в Postman
С помощью Postman можно быстро создать мок-серверы. Также на сайте Postman можно найти статьи с примерами инсценировки ответов в Postman и о совместной работе команды с использованием mock-серверов.
Динамическое обновление моков
В Postman легко создавать моки, возвращающие ответ. Однако, помимо генерации простого статического ответа, некоторые команды хотят добиться динамического обновления имитируемого ответа.
Рассмотрим другие возможности обновления мока:
- Создание нового мока.
- Добавление нового мока к существующей коллекции.
- Создание нового мока для существующей коллекции.
- Обновление мока для существующей коллекции.
- Передача значения из запроса в ответ.
- Возврат ответа на основе запроса.
Если вы хотите проследить за ходом работы в приложении Postman, то вы можете загрузить коллекцию и окружение с примерами запросов, нажав на оранжевую кнопку Run in Postman ниже, а также ознакомиться с документацией.
1. Создание нового мока
В Postman моки фактически представляют собой парный запрос и ответ, сохранённый в коллекции. Поэтому логично, что сначала нам нужно создать коллекцию, если её ещё нет. Для создания новой коллекции можно воспользоваться Postman API, а затем создать новый мок, связанный с этой коллекцией.
Требования:
- Ключ API Postman.
Шаги выполнения:
- Используйте Postman API для отправки
POST-запросана создание новой коллекции. - Используйте Postman API для отправки
POST-запросадля создания мока.
2. Добавление нового мока в существующую коллекцию
Допустим, у нас уже есть коллекция, в которую нужно добавить мок. Но для начала работы необходимо получить collection_uid (идентификатор коллекции).
Требования:
- Ключ API Postman.
collection_uid.
Шаги выполнения:
- Используйте Postman API для выполнения
GET-запросаи получения одной коллекции. - Добавление мока в коллекцию (с помощью скрипта Postman).
- Используйте Postman API для выполнения
PUT-запросадля обновления коллекции.
Примечание: если при экспорте коллекции Postman (версия 2.1) из приложения Postman отсутствуют заголовки, убедитесь, что заголовки ответа коллекции равны [] (пустой массив, вместо null).
3. Создание нового мока для существующей коллекции
Вы можете сгенерировать или извлечь информацию для изменения примера мока.
Шаги выполнения:
- Используйте Postman API для выполнения
GET-запросаи получения одной коллекции. - Выполните вычисления или сгенерируйте данные (с помощью скрипта).
- Используйте Postman API для
PUT-запросаи обновления коллекции.
Примечание: если при экспорте коллекции Postman (версия 2.1) из приложения Postman отсутствуют заголовки, убедитесь, что заголовки ответа коллекции равны o [] (пустой массив, а не null).
4. Обновление мока для существующей коллекции
Это аналогично примеру «Добавление мока в существующую коллекцию». Однако, сначала необходимо найти существующий пример мока для замены.
Шаги выполнения:
- Используйте Postman API для выполнения
GET-запросаи получения одной коллекции. - Найдите и обновите пример мока в JSON-коллекции (с помощью скрипта Postman).
- Используйте Postman API для выполнения
PUT-запросаи обновления коллекции.
Примечание: если при экспорте коллекции Postman (версия 2.1) из приложения Postman отсутствуют заголовки, убедитесь, что заголовки ответа коллекции равны [] (пустой массив, вместо null).
5. Передача значения из запроса в ответ
В этом примере вы можете ввести данные в запрос Postman, чтобы обновить пример мока (вместо ввода данных в редакторе переменных окружения).
Шаги выполнения:
- Используйте Postman API для выполнения
GET-запросаи получения одной коллекции. - Извлеките данные, например, из
POST-запросак образцу из Echo collection fetch request. Также можно использовать предыдущий запрос к другой конечной точке или получить данные с помощью скрипта Postman, например,pm.sendRequest(). - Используйте Postman API для выполнения
PUT-запросадля обновления коллекции.
Примечание: если при экспорте коллекции Postman (версия 2.1) из приложения Postman отсутствуют заголовки, убедитесь, что заголовки ответа коллекции равны [] (пустой массив, вместо null).
6. Возврат ответа на основе запроса
Для получения ответа нужно провести настройку элементов:
- Метод запроса — любой допустимый метод HTTP-запроса из сохранённого примера (например,
GET,POST,PUT,PATCH,DELETEи т. д.), который можно выбрать в качестве части запроса. - Путь запроса — любая допустимая строка пути (например,
/,/test,/test/path,/test/path/1), которую можно включить в URL запроса. x-mock-response-name— необязательный заголовок с именем сохранённого примера.x-mock-response-id— необязательный заголовок, содержащийuid(идентификатор) сохранённого примера.
Перевод статьи «Fake it till you make it: mocks for agile development».