Добрый день. Я занимаюсь автоматизацией тестирования. Как и у всех автоматизаторов, у меня есть набор библиотек и инструментов, которые я обычно выбираю для написания тестов. Но периодически возникают ситуации, когда ни одна из знакомых библиотек может решить задачу с риском сделать автотесты нестабильными или хрупкими. В этой статье я хотел бы рассказать, как вроде бы стандартная задача использования mock'ов привела меня к написанию своего модуля. Также хотел бы поделиться своим решением и услышать обратную связь.
Рубрика «mock»
Ещё одна библиотека для создания mock’ов
2019-11-21 в 13:32, admin, рубрики: mock, python, qa automation, автоматизация тестирования, Тестирование IT-систем, Тестирование веб-сервисовМоки, стабы и шпионы в Spock Framework
2019-01-09 в 8:09, admin, рубрики: groovy, Groovy & Grails, java, mock, spock, stub, tdd, Блог компании HaulmontSpock предоставляет 3 мощных (но разных по сути) инструмента, упрощающих написание тестов: Mock, Stub и Spy.
Довольно часто коду, который нужно протестировать, требуется взаимодействовать с внешними модулями, называющимися зависимостями (в оригинальной статье используется термин collaborators, который не очень распространён в русскоязычной среде).
Модульные тесты чаще всего разрабатываются для тестирования одного изолированного класса при помощи различных вариантов моков: Mock, Stub и Spy. Так тесты будут надёжнее и будут реже ломаться по мере того, как код зависимостей эволюционирует.
Такие изолированные тесты менее подвержены проблемам при изменении внутренних деталей реализации зависимостей.
От переводчика: каждый раз, когда я использую Spock Framework для написания тестов, я чувствую, что могу ошибиться при выборе способа подмены зависимостей. В этой статье есть максимально краткая шпаргалка по выбору механизма для создания моков.
Мок-сервер для автоматизации мобильного тестирования
2018-11-20 в 12:31, admin, рубрики: api, espresso, mock, mockserver, okhttpmockwebserver, Блог компании Maxilect, мок, тестирование, Тестирование IT-систем, Тестирование мобильных приложений, тестирование поРаботая над последним проектом, столкнулся с тестированием мобильного приложения, связанного на уровне бизнес-логики с различными сторонними сервисами. Тестирование этих сервисов не входило в мою задачу, однако проблемы с их API блокировали работу по самому приложению – тесты падали не из-за проблем внутри, а из-за неработоспособности API, даже не доходя до проверки нужной функциональности.
Традиционно для тестирования таких приложений используются стенды. Но они не всегда работают нормально, и это мешает работе. В качестве альтернативного решения я использовал моки. Об этом тернистом пути и хочу рассказать сегодня.
Как протестировать приложение при взаимодействии с API с помощью SoapUI
2018-11-10 в 15:36, admin, рубрики: api, groovy, mock, soapui, testing, Тестирование IT-системМногие используют SoapUI для того, чтобы тестировать как сам API, так и приложения, обращающиеся к API. Довольно гибкий инструмент, позволяющий, например, экспортировать swagger файл API и сгенерировать Mock-service на его основе.
Не так давно у нас в компании я столкнулся с похожей задачей, но с нетривиальными условиями. Исходные данные: необходимо протестировать серверное приложение, которое получает на вход задачу, в процессе выполнения обращается к АПИ, каждый последующий запрос зависит от ответа АПИ. Логика вшита в приложение. То есть своеобразный черный ящик, где нужно протестировать множество выходов из сценария, когда вход в сценарий один.
Ниже я предлагаю пример решения, которое позволило достаточно просто встроить его в регрессионную инфраструктуру, а также имеющее запас для масштабирования, в случае увеличения покрытия диапазона сценариев и их сложности.Читать полностью »
Практика написания Android-тестов. Лекция Яндекса
2018-01-07 в 12:27, admin, рубрики: android тестирование, assertj, espresso, hamcrest, junit, mock, test-driven development, UI-тесты, Блог компании Яндекс, интеграционное тестирование, разработка мобильных приложений, Разработка под android, тестирование, Тестирование мобильных приложений, тесты, юнит-тестыС праздниками, друзья! Если вы не против научиться на каникулах чему-то новому, прочитайте лекцию Кирилла Борисова — разработчика систем авторизации Яндекса. Кирилл объясняет, как построить процесс тестирования Android-приложений, знакомит с современными инструментами и спецификой их использования.
— Прежде чем двинуться вперед, давайте устроим небольшой соцопрос. Кто из вас знает, что такое тесты? Кто пишет тесты? А кто знает, зачем он пишет тесты? Читать полностью »
Моки и явные контракты
2017-09-16 в 16:08, admin, рубрики: Elixir, Elixir/Phoenix, mock, stub, testing, Совершенный код, тестирование, Тестирование IT-системНаверное каждый, кто начинал писать юнит и интеграционные тесты, сталкивался с проблемой злоупотребления моками, которая приводит к хрупким тестам. Последние, в свою очередь, создают у программиста неверное убеждение в том, что тесты только мешают работать.
Ниже представлен вольный перевод статьи, в которой José Valim — создатель языка Elixir — высказал своё мнение на проблему использования моков, с которым я полностью согласен.
Несколько дней назад я поделился своими мыслями по поводу моков в Twitter:
Мок — полезный инструмент в тестировании, но имеющиеся тестовые библиотеки и фреймворки зачастую приводят к злоупотреблению этим инструментом. Ниже мы рассмотрим лучший способ использования моков.
Применение MVP+TDD в разработке iOS приложений
2017-08-23 в 9:59, admin, рубрики: iOS, ios development, mock, mvp, swift, tdd, разработка под iOS— Слава TDD!
— Юнит-тестам слава!
В этой статье мы разберемся с принципами применения MVP+TDD в разработке iOS приложений. Разбираться будем на примере создания небольшой обучалки для пользователя, которая показывается при первом запуске.
Требования от бизнеса
Итак, ваш заказчик хочет, чтоб в его приложение добавили обучалку, которая покажется пользователю один раз при первом запуске. Обучалка состоит из нескольких изображений, которые должны быть показаны в определенной последовательности. Переключаться изображения должны по нажатию на кнопку "Продолжить". Также при показе последнего изображения — на кнопке нужно написать "Старт" (как бы намекая пользователю, что приложение будет сейчас запущено).
Читать полностью »
Mockанье зависимостей в node.js приложениях
2017-05-30 в 5:27, admin, рубрики: javascript, mock, node.js, proxyquire, stub, unit test, Программирование, Тестирование веб-сервисов, метки: proxyquireMocks, fakes, and stubs — три столпа юнит тестирования. Конечно же все знают что это такое, как солить и когда есть.
Я честно тоже так думал, пока не столкнулся с действительностью, под которую мне пришлось немного прогнуться.
Все началось очень просто — я сменил место работы, и первое что я увидел в новой кодовой базе — это тесты, их было немного больше чем кода. И посреди этих тестов была странная конструкция
Component = proxyquire.noCallThru().load(‘../Component’, {
‘../../core/selectors/common': { getData }
}).default;Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо
2016-01-19 в 13:49, admin, рубрики: mock, tdd, интеграционное тестированиеМногие программисты при выборе между интеграционным и юнит-тестом отдают предпочтение юнит-тесту (или, иными словами, модульному тесту). Некоторые считают интеграционные тесты антипаттерном, некоторые просто следуют модным тенденциям. Но давайте посмотрим, к чему это приводит. Для реализации юнит-теста mock-объекты навешиваются не только на внешние сервисы и хранилища данных, но и на классы, реализованные непосредственно внутри программы. При этом, если мокируемый класс используется в нескольких других классах, то и mock-объект будет содержаться в тестах на несколько классов. А поскольку тестируемое поведение принято задавать внутри теста (смотри given-when-then, arrange-act-assert, test builder), то поведение моки каждый раз заново задаётся в каждом тесте, и нарушается принцип DRY (хотя дублирования кода может и не быть). Кроме того, поведение класса декларируется в mock-объекте, но сама эта декларация не проверяется, поэтому со временем задекларированное в моке поведение может устареть и начать отличаться от реального поведения мокируемого класса. Это вызывает целый ряд сложностей:
1)Во-первых, при изменении функционала сложно вообще вспомнить, что помимо класса и тестов на него нужно изменить ещё и моки этого класса. Давайте рассмотрим цикл разработки в рамках TDD: «созданиеизменение тестов на функционал -> созданиеизменение функционала -> рефакторинг». Mock-объекты являются декларированием поведения класса и не имеют отношения ни к одной из этих трёх категорий (не являются тестами на функционал, несмотря на то, что в тестах используются, и уж тем более не являются самим функционалом). Таким образом, изменение mock-объектов классов, реализованных внутри программы, не укладывается в концепцию TDD.
2)Во-вторых, сложно найти все места мокирования этого класса. Я не встречал ни одного инструмента для этого. Тут можно или написать свой велосипед, или смотреть все места использования этого класса и отбирать те, где создаются моки. Но при неавтоматизированном поиске можно и ошибиться, проглядеть что-нибудь. Тут у вас, наверное возник вопрос: если проблема столь фундаментальна, как описывает автор, неужели никому не пришло в голову реализовать инструменты, упрощающие её решение? У меня есть гипотеза на этот счёт. Несколько лет назад я начал писать библиотеку, которая должна была собирать mock-объект так же, как IOC-контейнер собирает обычный класс, и автоматически создавать и прогонять тесты на поведение, описываемое в моках. Но затем я отказался от этой идеи, потому что нашёл более элегантное решение проблемы моков: просто не создавать эту проблему. Вероятно, по схожей причине специализированный инструмент для поиска моков конкретного класса или не реализован, или малоизвестен.
3)В-третьих, мест мокирования класса может быть много, и изменение их всех — рутинное занятие. Если программист вынужден делать рутину, которую невозможно автоматизировать, то это явный признак того, что с инструментами, архитектурой или рабочими процессами что-то не в порядке.
Надеюсь, суть проблемы ясна. Далее я опишу пути решения этой проблемы и расскажу, почему, с моей точки зрения, интеграционные тесты предпочтительнее юнит-тестов.
