Рубрика «mockserver»

Идея написать данную статью у меня возникла в самый обычный рабочий день, в момент когда ко мне от менеджеров в jira упала новая задачка. Сама задача была нормально заполнена - было и подробное описание, и ссылка на документацию с бизнес-требованиями, и приложены макеты.

Однако, её статус был не в “Ready for development”. Также можно было увидеть что сама задача ждёт выполнения другой задачи - на разработку API с данными. Здесь у меня начались вопросы, а также желание в очередной раз разъяснить менеджерам что критичных блокеров у этой задачи нет.

Читать полностью »

Работая над последним проектом, столкнулся с тестированием мобильного приложения, связанного на уровне бизнес-логики с различными сторонними сервисами. Тестирование этих сервисов не входило в мою задачу, однако проблемы с их API блокировали работу по самому приложению – тесты падали не из-за проблем внутри, а из-за неработоспособности API, даже не доходя до проверки нужной функциональности.

Традиционно для тестирования таких приложений используются стенды. Но они не всегда работают нормально, и это мешает работе. В качестве альтернативного решения я использовал моки. Об этом тернистом пути и хочу рассказать сегодня.

image
Читать полностью »

Ускоряйте тесты, говорили они.

И вот уже прошло почти полгода, как мы переписали свои старые необтёсанные, долгие и не стабильные функциональные тесты и перешли на быстрые, ни от чего не зависящие компонентные. Поэтому, пора делиться :)

Для тех кто не знает, компонентные тесты — это тесты которые полностью изолированы от глобального окружения и позволяют проверить те или иные кейсы, которые unit тест не смог бы охватить.

Полгода назад релиз какой-либо фичи, бывало занимало больше часа с учетом того, что код уже давно на мастере и полностью проверен, но мастер ветка никак не может добиться зеленой сборки в bamboo и тогда, встал вопрос, как дальше жить?
Читать полностью »

image

Иногда бывает необходимость написать небольшой АПИ сервис, часто в виде прототипа. И часто этот прототип потом так и остаётся в первоначально написанном виде следуя принципу «работает — не трогай». Переписывание даже относительно маленького сервиса сопряжено с возможностью внесения ошибки или случайного незначительно изменения поведения, которое обнаружится далеко не сразу. На помощь тут приходит тестирование по методу черного ящика (функциональное тестирование). Написание тестов является важной частью процесса разработки, а время потраченное на написание тестов может быть гораздо больше, чем реализация тестируемого функционала. Предлагаю рассмотреть метод тестирования, когда тестируемый код (сервис) и авто тесты написаны на разных языках программирование. Данный подход позволяет писать тесты без зависимости от первоначально выбранной технологии, что позволяет достаточно легко «выкинуть» прототип и переписать требуемый функционал на других технологиях. Плюс это демонстрация того, что тесты не обязательно должны быть написаны на том же языке, что и тестируемый сервис.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js