Разница между заглушками и драйверами
Есть много основных элементов, которые необходимы, чтобы сделать тестирование продукта простым и понятным. У каждого элемента есть своя собственная служебная функция, которая очень помогает при тестировании программного обеспечения и максимально обеспечивает ожидаемую функциональность в соответствии с документом SRS. Заглушки и драйверы – это два таких элемента, которые играют очень важную роль при тестировании; они заменяют модули, которые еще не разработаны, но все еще необходимы для тестирования других модулей на соответствие ожидаемым функциям и возможностям.
Заглушки и драйверы:
Заглушки и драйверы считаются элементами, которые эквивалентны модулям и могут быть заменены, если модули находятся на стадии разработки, отсутствуют или еще не разработаны. Таким образом, потребность в таких модулях могла быть удовлетворена. Драйверы и заглушки имитируют функции и функции и могут обслуживать функции, которые может предоставить модуль. Эти заглушки и драйверы сокращают ненужные задержки в тестировании и ускоряют процесс тестирования.
Заглушки в основном используются при тестировании интеграции сверху вниз, в то время как драйверы используются при тестировании интеграции снизу вверх, повышая эффективность процесса тестирования.
1. Заготовки:
Заглушки разрабатываются разработчиками программного обеспечения для использования их вместо модулей, если соответствующие модули не разработаны, отсутствуют. В стадии разработки или недоступен в настоящее время при нисходящем тестировании модулей. Эти заглушки имитируют модуль и обладают всеми возможностями, которые есть у недоступного модуля. Заглушки используются, когда модули нижнего уровня необходимы, но в настоящее время недоступны.
- Показывает отслеживаемые сообщения,
- Показывает отображаемое сообщение, если оно есть,
- Возвращает соответствующие значения, которые используются модулями,
- Возвращает значение выбранных параметров (аргументов), которые использовались модулями тестирования.
2. Драйверы:
Драйверы служат той же цели, что и заглушки, но драйверы используются при тестировании интеграции снизу вверх, а также более сложны, чем заглушки. Драйверы также используются, когда некоторые модули отсутствуют или недоступны во время тестирования конкретного модуля из-за некоторых неизбежных причин действовать в отсутствие необходимого модуля. Драйверы используются при отсутствии модулей высокого уровня, а также могут использоваться при отсутствии модулей более низкого уровня.
- Модуль-A: веб-сайт страницы входа,
- Модуль-B: Домашняя страница веб-сайта.
- Модуль-C: Настройка профиля
- Модуль-D: страница выхода
Всегда считается хорошей практикой начинать разработку всех модулей параллельно, потому что, как только каждый будет разработан, они могут быть интегрированы и могут быть протестированы дальше в соответствии с их соответствующим порядком взаимозависимостей с модулем. Но в некоторых случаях, если какой-либо из них находится в стадии разработки или недоступен в процессе тестирования конкретного модуля, вместо него можно использовать заглушки или драйверы.
Предположим, что модуль-A был разработан, как только он был разработан, он проходит тестирование, а тем временем для тестирования модуля-A требуется модуль-B, который еще не разработан и все еще находится в процессе разработки, поэтому в этом случае мы можем использовать заглушки или драйверы, которые имитируют все функции и возможности, которые могут быть показаны в фактическом модуле-B. Таким образом, можно сделать вывод, что заглушки и драйверы используются для удовлетворения потребности в недоступных модулях. Точно так же мы можем использовать заглушки или драйверы вместо Module-C и Module-D, если они тоже недоступны.
Обладают ли драйверы и заглушки одинаковыми функциями?
Да, мы можем сказать, что оба служат одной и той же функции и используются в отсутствие модуля (M 1 ), который имеет взаимозависимости с другим модулем (M 2 ), который необходимо протестировать, поэтому мы используем драйверы или заглушки, чтобы выполнять недоступность модуля (M 1 ) и обслуживать его функциональные возможности.
Тестируем интеграцию с внешними сервисами
Современные приложения редко работают в изоляции, чаще всего они интегрируются с множеством сторонних сервисов. Поэтому остро встает вопрос тестирования этой интеграции в рамках интеграционного или функционального тестирования. И тут можно наступить на многие грабли, о которых я и собираюсь поговорить. Для кого эта тема актуальна, прошу под кат.
В чем собственно проблема?
Первое решение, которое приходит в голову — тестировать напрямую на реальном сервисе. В некоторых случаях это может быть обосновано, но часто приводит к следующим проблемам:
- Тесты замедляются достаточно сильно. Доступ к внешнему сервису обычно осуществляется по сети с использованием публичных протоколов, что гораздо медленнее локальной интеграции. Внешний сервис обычно не такой быстрый и подвержен собственной нагрузке, во время которой может замедляться еще сильнее. В результате я встречал на практике замедление интеграционного набора тестов с 10 минут до пары часов, причем время выполнения сильно плавало.
- Тесты становятся менее стабильными. Как я уже говорил, внешние сервисы подвержены нагрузкам, иногда недоступны из-за обновлений, «падают» при неверном обновлении разработчиками сервиса, ну и сетевые ошибки также не исключены. Все это очень сильно влияет на ваш тестовый набор и его стабильность. Тесты «падают» неожиданно, на изучение проблемы уходит много времени и члены команды начинают недоверчиво относиться к тестам в целом. В результате сама полезность тестирования может быть поставлена под сомнение.
- Вы просто не имеете возможность получить некоторые ответы внешнего сервиса (ошибки, специфические данные и т.д.), что может сказаться на покрытии вашего кода тестами, а значит надежности регрессионного тестирования интеграционными тестами. Ведь нужно покрывать не только позитивные, но и негативные сценарии.
- Реальный сервис не всегда имеет тестовый интерфейс и вам приходится использовать совершенно реальный. А это не всегда бесплатно и любые ошибки в вашем коде подвергают риску реальные данные на внешнем сервисе. Благодаря этой проблеме можно легко удалить очень важные данные или заблокировать доступ из реального приложения. И это не говоря о том, что много денег может быть потрачено на «неожиданное» использование внешнего сервиса.
Описанные проблемы заставляют вас искать альтернативные решения и они существуют.
Заглушки правят миром тестирования!
На помощь вам могут придти разнообразные варианты заглушек (не нашел лучшего перевода термина mock objects). Есть несколько вариантов заглушек: mock, stub, dummy, spy, fake. Знать и различать их нужно и важно, поэтому стоит почитать и разобраться в специфике, но речь пойдет не об этом. Нам понадобится только один из видов заглушек, который наиболее подходит для работы с внешними сервисами — fake реализация.
Fake реализация представляет из себя упрощенный вариант настоящего сервиса, который работает полностью предсказуемо, локально, дает полный доступ к данным и настройкам, а также не требует никакой дополнительной работы в каждом тесте. Таким образом, мы сможем прозрачно заменить настоящий сервис в тестах на fake реализацию и решить все проблемы. Звучит просто? Не очень!
Во-первых, нам нужно будет реализовать этот упрощенный вариант сервиса, на что понадобится время и усилия разработчиков. Вы счастливчик, если ваш внешний сервис предоставляет fake реализацию для локального тестирования. Тогда вы просто скачиваете библиотеку, настраиваете, запускаете и пользуетесь на здоровье. Некоторые сервисы позволяют получить доступ к специальной версии внешнего сервиса для тестирования, которая не подвержена перечисленным в первой части проблемам. Но таких сервисов единицы. Почти всегда вам придется писать fake реализацию самостоятельно.
Во-вторых, вам придется позаботиться о том, чтобы ваша fake реализация ведет себя так же как реальный сервис. Это одни из самых частых граблей, на которые наступают сторонники описанного подхода. Вы делаете fake реализацию сегодня, а через неделю реальный сервис начинает вести себя по-другому. Ваши тесты по-прежнему проходят и вы спокойно живете пока не задеплоите ваш код на «живые» сервера. И вот там вас ждет неприятный сюрприз!
Эту проблему очень легко исправить, но придется приложить еще немного усилий. Вам нужно написать еще один набор тестов, теперь уже на реальный сервис, целью которого будет контроль и поддержание надежности протокола между вашим приложением и сторонним сервисом. Это некоторый вариант smoke тестов на внешний сервис, которые можно запускать раз в час, день или неделю в зависимости от стабильности вашего внешнего сервиса. Тогда вы действительно контролируете и тестируете интеграцию с внешним сервисом и избегаете сюрпризов при его изменении.
Я не готов к таким изменениям!
Описанное решение подходит не всем (в принципе как и любое другое). Поэтому я дам несколько советов, с помощью которых вы можете немного сгладить проблемы из первой части этой статьи.
- Разделяйте тесты на те, где вам нужна интеграция в внешними сервисами, и те, где важна только внутренняя функциональность вашего продукта. Приведу пару простых примеров. Если вы тестируете регистрацию, то вам наверняка не так важна система показа рекламы, подтягивание последних записей из Twitter и т.д. Поэтому внешние сервисы можно и нужно отключать. В каждом приложении это можно сделать по-своему. Например, в веб-приложении очень просто использовать контролируемый прокси, который может в любое время перекрыть доступ к одному из внешних сервисов. Такая простая мера позволит вам очень сильно ускорить ваши тесты.
- Активно используйте настраиваемое кэширование для получения данных из внешних сервисов. Обычно при интеграционном или функциональном тестировании вы проходите одни и те же части приложения неоднократно, при этом не всегда есть потребность в обновленных данных. Поэтому можно сильно сэкономить на вызовах внешних сервисов, закэшировав результаты предыдущего вызова. Таким образом, вы все еще тестируете получение реальных данных, но гораздо оптимальнее.
- Обязательно поищите open source fake решение для вашего сервиса. Обычно для популярных сервисов оно существует, так как с подобной задачей тестирования сталкивается много людей и не все из них такие ленивые как вы. Например, есть замечательный проект fake-s3 для работы с Amazon S3 сервисом. Он реализует тот же API, позволяя тестировать интеграцию бесплатно, безопасно и локально. Все что вам необходимо — это возможность конфигурации доступа к сервису в вашем приложении.
- Узнайте у провайдера сервиса, есть ли у него возможности для локализации тестирования. Возможно, вы просто не знаете о существовании подобных решений или подтолкнете провайдера к его созданию. За спрос не бьют, как говорится.
Кому-то даже этот набор мер позволит существенно улучшить свое тестирование.
Заключение
А вообще, самое главное — это понимать описанные проблемы и иметь желание их разрешить. Тогда можно придумать множество альтернативных решений и подходов, которые будут работать еще лучше приведенных в статье для вашего конкретного случая. И тогда ваши тесты снова будут быстрыми, надежными и еще более полезными для вашей команды.
Использование заглушек для изоляции частей приложений друг от друга при модульном тестировании
Типы заглушек — это одна из двух технологий, которые платформа Microsoft Fakes предоставляет для более простого изолирования тестируемого компонента от других вызываемых компонентов. Заглушка — это небольшая часть кода, которая заменяет собой другой компонент во время тестирования. Преимущество использования заглушки заключается в том, что она возвращает последовательные результаты, упрощая написание теста. Тесты можно выполнять, даже если другие компоненты пока не работают.
Обзор и рекомендации по быстрому началу работы с Fakes см. в статье Изоляция тестируемого кода с помощью Microsoft Fakes.
Для использования заглушек необходимо написать компонент таким образом, чтобы он использовал только интерфейсы, а не классы для ссылки на другие части приложения. Это рекомендуемая практика разработки, поскольку при внесении изменений в одну часть, скорее всего, не потребуется вносить изменения в другую. При тестировании это позволяет заменить заглушку на реальный компонент.
На схеме представлен компонент StockAnalyzer, который требуется протестировать. Обычно он использует другой компонент — RealStockFeed. Но RealStockFeed возвращает различные результаты при каждом вызове его методов, что усложняет тестирование StockAnalyzer. Во время тестирования мы заменяем этот компонент на другой класс — StubStockFeed.
Поскольку предполагается, что заглушки могут структурировать код таким образом, они обычно используются для изолирования одной части приложения от другой. Для изолирования ее от других сборок, которыми вы не можете управлять, например System.dll, обычно используются оболочки. См. статью Использование оболочек совместимости для изоляции приложения от других сборок при модульном тестировании.
Использование заглушек
Разработка для внедрения зависимости
Для использования заглушек приложение должно быть разработано таким образом, чтобы различные компоненты не зависели друг от друга, а только от определений интерфейса. Вместо соединения во время компиляции компоненты соединяются во время выполнения. Этот шаблон позволяет создать надежное и легко обновляемое программное обеспечение, поскольку изменения, как правило, не выходят за границы компонентов. Им рекомендуется пользоваться, даже если вы не используете заглушки. При написании нового кода легко использовать шаблон внедрения зависимости. При написании тестов для существующего программного обеспечения может потребоваться выполнить его рефакторинг. Если это непрактично, можно рассмотреть возможность использования оболочек.
Начнем с показательного примера, представленного на схеме. Класс StockAnalyzer считывает курсы акций и выдает некоторые интересные результаты. Он имеет несколько открытых методов, которые требуется протестировать. Для простоты рассмотрим только один из этих методов, который сообщает текущий курс определенной акции. Требуется написать модульный тест этого метода. Вот первый вариант теста.
Одна проблема с данным тестом немедленно бросается в глаза: курсы акции различаются, поэтому утверждение обычно будет выдавать ошибку.
Другая проблема может заключаться в том, что компонент StockFeed, который используется классом StockAnalyzer, в данный момент находится в разработке. Вот первый вариант кода тестируемого метода.
В таком виде этот метод может не компилироваться или может вызвать исключение, поскольку работа над классом StockFeed еще не завершена. Внедрение интерфейса позволит решить обе эти проблемы. При внедрении интерфейса применяется следующее правило:
Код любого компонента приложения не должен явно ссылаться на класс в другом компоненте ни в объявлении, ни в операторе new . Вместо этого переменные и параметры необходимо объявлять с помощью интерфейсов. Экземпляры компонента должны создаваться только в контейнере компонента.
“Компонент” означает класс или группу классов, которые разрабатываются и обновляются вместе. Обычно компонент — это код в одном проекте Visual Studio. Отделять классы в одном компоненте не так важно, поскольку они обновляются одновременно.
Также не имеет особого значения отделять компоненты от классов относительно стабильной платформы, например System.dll. Если написать интерфейсы для всех этих классов, код будет перегружен.
Вы можете отделить код StockAnalyzer от StockFeed с помощью интерфейса следующим образом:
В этом примере классу StockAnalyzer передается реализация IStockFeed при построении. В готовом приложении код инициализации выполнил бы следующее подключение.
Существуют более гибкие способы выполнения этого подключения. Например, StockAnalyzer может принять объект фабрики, который может создать экземпляры различных реализаций IStockFeed в различных условиях.
Создание заглушек
Вы отделили класс, который необходимо протестировать, от других используемых им компонентов. Такое отделение позволяет не только сделать приложение более надежным и гибким, но и подключить тестируемый компонент к реализациям заглушки интерфейсов для тестирования.
Достаточно написать заглушки как классы обычным способом. Однако Microsoft Fakes предлагает более динамический способ создания наиболее подходящей заглушки для каждого теста.
Чтобы использовать заглушки, необходимо сначала создать типы заглушек из определений интерфейса.
Добавление сборки Fakes
В Обозревателе решений выполните следующие действия:
- Для более старого проекта .NET Framework (не в стиле пакета SDK) разверните узел Ссылки проекта модульного теста.
- Для проекта в стиле SDK, предназначенного для .NET Framework, .NET Core или .NET 5.0 или более поздних версий, разверните узел Зависимости, чтобы найти сборку, которую нужно имитировать в разделе Сборки, Проекты или Пакеты.
- При работе в Visual Basic на панели инструментов Обозревателя решений необходимо выбрать команду Показать все файлы, чтобы просмотреть узел Ссылки.
Выделите сборку, содержащую определения классов, для которых необходимо создать оболочки. Например, если требуется создать оболочку для DateTime, выберите System.dll.
В контекстном меню щелкните Добавить сборку имитаций.
Создание теста с заглушками
Особую роль здесь играет класс StubIStockFeed . Для каждого открытого типа в сборке, на которую указывает ссылка, механизм Microsoft Fakes создает класс заглушки. Имя класса заглушки является производным от имени интерфейса, где Fakes.Stub — это префикс, за которым следуют имена типов параметров.
Заглушки также создаются для методов получения и задания свойств, для событий и для универсальных методов.
Проверка значений параметров
Можно проверить, что компонент передает правильные значения, когда вызывает другой компонент. Можно поместить утверждение в заглушку или сохранить значение и проверить его в основной части теста. Пример:
Заглушки для различных видов членов типа
Методы
Как описано в примере, методы могут быть заменены заглушками путем добавления делегата в экземпляр класса заглушки. Имя типа заглушки является производным от имен метода и параметров. Например, даны следующие интерфейс IMyInterface и метод MyMethod .
Мы присоединяем заглушку к методу MyMethod , который всегда возвращает значение 1.
Если не предоставить заглушку для функции, Fakes создает функцию, возвращающую значение по умолчанию возвращаемого типа. Для чисел значением по умолчанию является 0, а для типов классов — null (C#) или Nothing (Visual Basic).
Свойства
Методы получения и задания свойств представляются как отдельные делегаты и могут быть заменены заглушками отдельно. Например, рассмотрим свойство Value интерфейса IMyInterface .
Мы присоединяем делегаты к методам получения и задания свойства Value , чтобы сымитировать автосвойство.
Если не предоставить методы-заглушки для метода получения или задания свойства, Fakes создает заглушку, хранящую значения, чтобы свойство заглушки выступало в роли простой переменной.
События
События представляются как поля делегата. В результате любые события, замененные заглушками, могут вызываться путем вызова резервного поля события. Рассмотрим следующий интерфейс, который требуется заменить заглушкой.
Чтобы вызвать событие Changed , достаточно вызвать резервный делегат.
Универсальные методы
Чтобы заменить универсальные методы заглушками, предоставьте делегат для каждого требуемого экземпляра метода. Например, рассмотрим следующий интерфейс, содержащий универсальный метод.
Можно написать тест, в котором экземпляр GetValue заменяется заглушкой:
Если бы код вызвал GetValue с любым другим экземпляром, то заглушка просто вызвала бы поведение.
Заглушки виртуальных классов
В предыдущих примерах заглушки создавались из интерфейсов. Заглушки также можно создавать из класса с виртуальными или абстрактными членами. Пример:
В заглушке, созданной из этого класса, можно задать методы делегата для DoAbstract() и DoVirtual() , но не для DoConcrete() .
Если не предоставить делегат для виртуального метода, Fakes может предоставить поведение по умолчанию или вызвать метод в базовом классе. Чтобы вызывался базовый метод, задайте свойство CallBase .
Заглушки отладки
Типы заглушек призваны обеспечить бесперебойную отладку. По умолчанию отладчик должен обходить любой создаваемый код, чтобы сразу переходить к пользовательским реализациям членов, которые присоединены к заглушке.
Ограничения заглушки
Сигнатуры методов с указателями не поддерживаются.
Запечатанные классы или статические методы не могут быть заменены заглушками, поскольку типы заглушек зависят от диспетчеризации виртуальных методов. В таких случаях используйте типы оболочек, которые описываются в статье Использование оболочек совместимости для изоляции приложения от других сборок при модульном тестировании.
Изменение поведения заглушек по умолчанию
Каждый созданный тип заглушки содержит экземпляр интерфейса IStubBehavior (через свойство IStub.InstanceBehavior ). Поведение вызывается каждый раз, когда клиент вызывает член без присоединенного пользовательского делегата. Если поведение не задано, используется экземпляр, возвращаемый свойством StubsBehaviors.Current . По умолчанию это свойство возвращает поведение, вызывающее исключение NotImplementedException .
Это поведение можно изменить в любое время, задав свойство InstanceBehavior в любом экземпляре заглушки. Например, в следующем фрагменте кода изменяется поведение, которое ничего не делает или возвращает значение по умолчанию для возвращаемого типа default(T) .
Поведение также можно изменить глобально для всех объектов заглушки, для которых не было задано поведение, путем задания свойства StubsBehaviors.Current .
Что такое заглушка в программировании
Тестирование компонента заключается в подаче входных данных в его интерфейс, ожидании ответа компонента и проверки полученных результатов. В процессе работы компоненты часто пользуются другими компонентами, передают им данные и используют полученную от них информацию:
Рисунок 1: Тестирование реализованного компонента
Эти другие компоненты могут вызывать сложности при тестировании:
- Они могут быть еще не реализованы.
- В них могут быть ошибки, нарушающие работу тестов, причем на выяснение того, что ошибка была вызвана не тестируемым, а зависимым компонентом, может уйти много времени и усилий.
- Компоненты могут затруднять тестирование тогда, когда это действительно надо. Например, если компонент – коммерческая база данных, у вас может оказаться недостаточно лицензий для всех пользователей. Другой пример: компонент может представлять собой аппаратное обеспечение, доступное только в определенные промежутки времени в определенной лаборатории.
- Компоненты могут настолько замедлить тестирование, что станет невозможно выполнять тесты достаточно часто. Например, инициализация базы данных может занимать пять минут.
- Может быть сложно поставить компонент в условия, при которых он выдаст ожидаемый от него результат. Например, перед вами может стоять задача протестировать обработку сообщения “диск переполнен” для всех методов, осуществляющих запись на диск. Как гарантировать, что диск будет заполнен именно на момент вызова нужного метода?
Во избежание возникновения таких сложностей можно пользоваться заглушками компонентов (другое название заглушек – имитаторы). Заглушки должны вести себя так же, как вели ли бы себя реальные компоненты, на тех входных данных, которые они могут получить в ходе тестирования. Однако это только задача-минимум: в качестве заглушек можно использовать и полноценные эмуляторы, с максимальной точностью имитирующие поведение реального компонента. Например, довольно часто имеет смысл создание программных заглушек для аппаратного обеспечения. Они будут вести себя точно так же, как аппаратное обеспечение, только работать медленнее. Применение таких заглушек упрощает отладку, снимает проблему недостатка единиц оборудования, и наконец, ими можно пользоваться еще до завершения разработки оборудования.
Рисунок 2: Тестирование компонента с заглушкой вместо компонента, от которого он зависит
У заглушек есть два недостатка.
- Заглушки могут быть дорогостоящими (это особенно актуально для эмуляторов). Поскольку заглушки сами по себе представляют программное обеспечение, они нуждаются в обслуживании.
- Заглушки могут маскировать ошибки. Например, предположим, что ваш компонент пользуется тригонометрическими функциями, но к настоящему моменту соответствующая библиотека еще не разработана. Вы пользуетесь тремя тестами для вычисления синуса трех углов: 10 градусов, 45 градусов и 90 градусов. Вы находите нужные значения с помощью калькулятора и строите заглушку функции синуса, которая возвращает на эти входные параметры значения 0,173648178, 0,707106781 и 1,0, соответственно. Все прекрасно работает до момента интеграции компонента в готовую библиотеку, в которой функция синуса принимает на входе значения в радианах и возвращает значения -0,544021111, 0,850903525 и 0,893996664. В итоге вы обнаруживаете ошибку в коде позже и потратив больше усилий, чем хотелось бы.
Заглушки и практика разработки программного обеспечения
Иногда заглушки создаются только потому, что реальный компонент еще не доступен на момент тестирования. Во всех остальных случаях заглушки следует сохранять после завершения разработки. Скорее всего, тесты, поддерживаемые заглушками, будут важны при обслуживании продукта. Поэтому качество заглушек должно быть выше, чем качество кода на выброс. Хотя к качеству заглушек не предъявляются настолько жесткие требования, как к коду продукта (например, большинство заглушек не нуждается в собственных тестах), в дальнейшем некоторые из них придется обслуживать в процессе изменения продукта. Если обслуживание будет требовать слишком больших усилий, заглушки будут выброшены, и инвестиции в них будут потеряны.
Заглушки влияют на структуру компонентов – особенно в случаях, когда они сохраняются на будущее. Например, предположим, что компонент будет хранить пары из ключей и значений в базе данных. Сравним два сценария разработки:
Сценарий 1: база данных используется как для тестирования, так и для работы. . Существование базы данных не нужно скрывать от компонента. Можно даже инициализировать компонент с именем базы данных:
И хотя вряд ли вы будете пользоваться операторами SQL для всех операций чтения и записи значений, почти наверняка операторы SQL будут, по крайней мере, в нескольких методах. Например, компонент, нуждающийся в значении, может вызывать следующий метод:
В тестах пары из ключей и значений KeyValuePairs будут реализованы с помощью какой-нибудь простой конструкции, например таблицы:
За исключением периода тестирования, компонент будет пользоваться адаптером, преобразующим вызовы KeyValuePairs в операторы SQL:
У компонента может быть один и тот же конструктор для тестирования и реальной эксплуатации. Этот конструктор может принимать имя объекта, реализующего KeyValuePairs . Как вариант, конструктор может предоставлять данный интерфейс только для тестирования и требовать, чтобы реальные клиенты компонента передавали имя базы данных:
Поэтому с точки зрения программиста получилось, что два сценария проекта порождают один и тот же API, но один из этих сценариев проще в тестировании. К тому же учтите, что некоторые тесты могут пользоваться реальной базой данных, а некоторые – заглушкой.
Дополнительная информация
- Endo-Testing: Unit testing with Mock Objects, “eXtreme Programming and Flexible Processes in Software Engineering – XP2000”. © 2000 Tim Mackinnon, Steve Freeman, Philip Craig.
- (Загрузить Adobe Reader)
- Инструмент: Rational QualityArchitect
- Инструмент: Rational Test RealTime
Что означает “заглушить” в программировании?
интеграция с внешним API является почти гарантией в любом современном веб-приложении. Чтобы эффективно протестировать такую интеграцию, вам нужно заглушки его. Хороший заглушки должно быть легко создавать и последовательно обновляться с фактическими, текущими ответами API. В этом посте мы изложим стратегию тестирования, используя заглушки для внешнего API.
6 ответов
заглушка является управляемой заменой для Существующих Зависимостей (или коллаборационист) в системе. Используя заглушку, вы можете проверить свой код без борьбы с зависимостью напрямую.
Внешняя Зависимость-Существующая Зависимость:
Это объект в вашей системе, который ваш код под тестом взаимодействует и над которым у вас нет контроля. (Общий примерами являются файловые системы, потоки, память, время и так далее.)
Например в приведенном ниже коде:
вы хотите проверить mailService.Отправка электронных писем отключена() метод, но для этого вам нужно смоделировать исключение в вашем методе тестирования, так что вам просто нужно создать поддельный заглушка errorService объект для имитации результата, который вы хотите, тогда ваш тестовый код сможет протестировать mailService.Отправка электронных писем отключена() метод. Как вы видите, вам нужно смоделировать результат, который из другой зависимости, которая ErrorService объект класса (существующий объект зависимости).
A заглушки, в этом контексте, означает макет реализации.
то есть простая, поддельная реализация, которая соответствует интерфейсу и должна использоваться для тестирования.
термины непрофессионала, это фиктивные данные (или поддельные данные, тестовые данные. так далее.) который можно использовать для тестирования или разработки кода до тех пор, пока вы (или другая сторона) не будете готовы представить/получить реальные данные. Это программистский “Lorem Ipsum”.
база данных сотрудников не готова? Придумай что-нибудь простое с Джейн Доу, Джон Доу. так далее. API не готов? Сделайте фальшивку, создав статику .файл json, содержащий поддельные данные.
в этом контексте слово “заглушка” используется вместо “mock”, но ради ясности и точности автор должен был использовать “mock”, потому что “mock” – это своего рода заглушка, но для тестирования. Чтобы избежать дальнейшей путаницы, нам нужно определить, что такое заглушка.
В общем контексте заглушка – это часть программы (обычно функция или объект), которая инкапсулирует сложность вызова другой программы (обычно расположенной на другой машине, виртуальной машине или процессе, но не всегда, это также может быть локальный объект). Поскольку фактическая программа для вызова обычно не находится в одном и том же пространстве памяти, для ее вызова требуется множество операций, таких как адресация, выполнение фактического удаленного вызова, маршалинг/сериализация передаваемых данных/аргументов (и то же самое с потенциальным результатом), возможно, даже работа с аутентификацией/безопасностью и т. д. Обратите внимание, что в некоторых контекстах заглушки также называются прокси (например, динамические прокси в Java).
макет очень специфический и ограничительный вид заглушки, потому что макет-это замена другой функции или объекта для тестирования. На практике мы часто используем mocks в качестве локальных программ (функций или объектов) для замены удаленной программы в тестовой среде. В любом случае макет может имитировать фактическое поведение замененной программы в ограниченном контексте.
самые известные виды заглушек очевидно для распределенного программирования, когда вызывать удаленные процедуры (RPC) или удаленные объекты (RMI, описание). Большинство распределенных программных фреймворков / библиотек автоматизируют генерацию заглушек, так что вам не нужно писать их вручную. Заглушки могут быть сгенерированы из определения интерфейса, написанного с помощью IDL например (но вы также можете использовать любой язык определения интерфейсов).
типично, в RPC, RMI, CORBA, и так далее, одно различает заглушки на стороне клиента, которые в основном заботятся о маршалинге / сериализации аргументов и выполнении удаленного вызова, и серверные стабы, которые в основном заботятся о unmarshaling / десериализации аргументов и фактически выполняют удаленную функцию/метод. Очевидно, что клиентские заглушки расположены на стороне клиента, в то время как заглушки sever (часто называемые скелетами) расположены на стороне сервера.
написание хороших эффективных и общих заглушек становится довольно сложным при работе со ссылками на объекты. Большинство фреймворков распределенных объектов, таких как RMI и CORBA, имеют дело со ссылками на распределенные объекты, но большинство программистов избегают этого, например, в средах REST. Как правило, в средах REST программисты JavaScript делают простые функции заглушки для инкапсуляции вызовов AJAX (сериализация объектов поддерживается JSON.parse и JSON.stringify ). The Swagger Codegen проект обеспечивает обширное поддержка автоматического создания заглушек REST на разных языках.
У вас также есть очень хорошие рамки тестирования для создания такого заглушки. Один из моих предпочтительных Mockito появилась EasyMock и другие. Но Mockito велик, вы должны прочитать его – очень элегантный и мощный пакет
заглушка-это определение функции, которое имеет правильное имя функции, правильное количество параметров и выдает фиктивный результат правильного типа.
Это помогает написать тест и служит своего рода лесов, чтобы сделать возможным запустить примеры еще до завершения проектирования функции
Что значит «заглушить» в программировании?
Интеграция с внешним API – это почти гарантия любого современного веб-приложения. Чтобы эффективно протестировать такую интеграцию, вам нужно заглушить ее. Хорошую заглушку должно быть легко создать, и она должна постоянно обновляться с учетом актуальных ответов API. В этом посте мы опишем стратегию тестирования с использованием заглушек для внешнего API.
Заглушка – это управляемая замена существующей зависимости (или сотрудника) в системе. Используя заглушку, вы можете протестировать свой код, не обращаясь напрямую к зависимости.
Внешняя зависимость – существующая зависимость:
это объект в вашей системе, с которым ваш тестируемый код взаимодействует и над которым вы не можете контролировать. (Общие примеры – файловые системы, потоки, память, время и т. Д.)
Например, в коде ниже:
Вы хотите протестировать метод mailService.SendEMail () , но для этого вам нужно смоделировать исключение в вашем тестовом методе, поэтому вам просто нужно создать объект Fake Stub errorService для имитации желаемого результата, тогда ваш тестовый код будет возможность протестировать метод mailService.SendEMail () . Как видите, вам нужно смоделировать результат, полученный от другой зависимости, которая является объектом класса ErrorService (существующий объект зависимости).
@ Jwan622 Проще говоря: все, что используется в коде. Это может помочь понять, если вы перечитаете и замените «зависимость» на «класс» или «функцию» или что-то еще (в зависимости от вашего опыта). Иногда использование существующего класса / функции не является жизнеспособным вариантом, и вам нужна заглушка (например, при автоматическом модульном тестировании для функций, которые зависят от среды, такой как текущая дата и время системы).
Окурка , в этом контексте означает макет реализации.
То есть простая поддельная реализация, соответствующая интерфейсу и предназначенная для тестирования.
Более подробная информация представлена в известной статье Мартина Фаулера « Mocks Aren’t Stubs» : «Но очень часто я вижу, что макетные объекты описываются плохо. В частности, я вижу, что их часто путают с заглушками – обычным помощником для сред тестирования».
По словам непрофессионала, это фиктивные данные (или поддельные данные, тестовые данные и т. Д.), Которые вы можете использовать для тестирования или разработки своего кода, пока вы (или другая сторона) не будете готовы представить / получить реальные данные. Это программистский “Lorem Ipsum”.
База данных сотрудников не готова? Придумайте простой вариант с Джейн Доу, Джоном Доу . и т. Д. API не готов? Создайте поддельный, создав статический файл .json, содержащий поддельные данные.
В этом контексте слово «заглушка» используется вместо «макет», но для ясности и точности автору следовало использовать «макет», потому что «макет» – это своего рода заглушка, но для тестирования. Чтобы избежать дальнейшей путаницы, нам нужно определить, что такое заглушка.
В общем контексте заглушка – это часть программы (обычно функция или объект), которая инкапсулирует сложность вызова другой программы (обычно расположенной на другом компьютере, виртуальной машине или процессе, но не всегда, она также может быть локальной. объект). Поскольку фактическая вызываемая программа обычно не находится в одном и том же пространстве памяти, ее вызов требует множества операций, таких как адресация, выполнение фактического удаленного вызова, маршалинг / сериализация данных / аргументов, которые необходимо передать (и то же самое с потенциальным результатом), может даже иметь дело с аутентификацией / безопасностью и так далее. Обратите внимание, что в некоторых случаях заглушки также называются прокси (например, динамические прокси в Java).
Мок – это очень специфический и ограничивающий вид заглушки, потому что макет – это замена другой функции или объекта для тестирования. На практике мы часто используем моки в качестве локальных программ (функций или объектов) для замены удаленной программы в тестовой среде. В любом случае макет может имитировать реальное поведение замененной программы в ограниченном контексте.
Наиболее известные виды заглушек, очевидно, предназначены для распределенного программирования, когда необходимо вызывать удаленные процедуры ( RPC ) или удаленные объекты ( RMI , CORBA ). Большинство фреймворков / библиотек распределенного программирования автоматизируют создание заглушек, поэтому вам не нужно писать их вручную. Заглушки можно сгенерировать из определения интерфейса, написанного, например, с помощью IDL (но вы также можете использовать любой язык для определения интерфейсов).
Обычно в RPC, RMI, CORBA и т. Д. Различают заглушки на стороне клиента , которые в основном заботятся о маршалинге / сериализации аргументов и выполнении удаленного вызова, и заглушки на стороне сервера , которые в основном заботятся о демаршалинге / десериализации. аргументы и фактически выполнить удаленную функцию / метод. Очевидно, что клиентские заглушки расположены на стороне клиента, а заглушки серверов (часто называемые скелетами) расположены на стороне сервера.
Написание хороших эффективных и универсальных заглушек становится довольно сложной задачей при работе со ссылками на объекты. Большинство сред распределенных объектов, таких как RMI и CORBA, имеют дело со ссылками на распределенные объекты, но большинство программистов этого избегают, например, в средах REST. Обычно в средах REST программисты JavaScript создают простые функции-заглушки для инкапсуляции вызовов AJAX (сериализация объектов поддерживается с помощью JSON.parse и JSON.stringify ). Проект Swagger Codegen предоставляет обширную поддержку для автоматического создания заглушек REST на различных языках.
Прототипирование без API
Я из тех, кто обычно очень нетерпелив, когда менеджер раскрывает функции нового продукта. После спринта я задаю этот ужасающий, трепещущий вопрос:
И ответ часто отрицательный. Иногда коллеги по бэкенду заняты другими делами и не могут предоставить даже заглушку. Но ничего страшного! Если у вас есть жизнеспособный интерфейс объекта переноса данных, с которым согласны коллеги, вы можете начать создавать новые функции.
Минимизируем изменения для интеграции: используем Injectables и будем работать на двух клиентах API одновременно:
- Первый — заглушка, назовём её MockPriceApiService .
- Второй — реальный сервис, он будет поставляться приложением, когда API будет готов. Его мы назовём PriceApiService .
- Классы реализуют интерфейс, устанавливающий контракт между API.
Ещё раз. Я создам минимальное приложение для криптовалюты. Оно будет работать как с поддельными ценами, так и с реальным сервисом Coincap. Читать лень? Посмотрите готовый проект Stackblitz!
Общий интерфейс
Во-первых, мы хотим определить общий интерфейс для классов API. Создаём ApiService :
Как видите, сервисам нужно только два общих метода:
- Первый — подписка на поток цен.
- Второй — отписка от него.
Заглушка
Начнём с сервиса-заглушки. Вот, что нужно реализовать:
- Получение потока случайных чисел (цен). Он будет основан на базовых ценах, чтобы приблизить числа к реальным.
- Отписка от потока.
Приложение поддерживает 3 валюты: биткоин, лайткоин и эфириум.
О методе getPrice :
- Метод принимает параметр currency — имя валюты.
- Таймер срабатывает через 250 мс.
- Замораживаем оповещённую Observable на 1 секунду, имитируя задержку сети.
- Берём BASE_PRICE выбранной валюты и каждый раз возвращаем случайное число.
- Повторяем до оповещения от Subject .
Реальный сервис
Как мы уже говорили, вашей команде может потребоваться некоторое время, прежде чем будет предоставлен реальный API для внедрения в ваш интерфейс. Если команда уже согласилась с интерфейсом, ничто не мешает вам реализовать API заранее и создать реальный сервис вместе с имитацией.
Чтобы завершить пример, создадим реальный сервис и возьмём цены у Coincap. Будем использовать WebSocket для потоковой передачи цен нашим клиентам.
Два открытых общих метода будут:
- Создавать соединение WebSocket и поток цен через Observable .
- Закрывать соединение при вызове unsubscribe . Поток перестаёт отправлять цены.
Данные для сервиса
Теперь давайте покажем, как использовать данные, передаваемые любыми из двух сервисов. Ниже компонент, внедряющий PriceApiService :
- Мы создаем свойство price , которому назначаем поток.
- Когда пользователь меняет валюту, мы вызываем метод отписки, если валюта не выбрана.
Вот, что в шаблоне:
- Отображаем цену.
- Если цена не определена, но валюта выбрана, значит, подписка действует. Показываем загружаемое сообщение.
- Валюта не выбрана? Тогда сообщение пустое.
Переключаем сервисы
Здесь — магия. Благодаря внедрению зависимости мы можем предоставить нужный нам сервис, передав ему имя класса. Если useMocks истинна, используем MockPriceApiService , иначе PriceApiService .
Конечно, пока конечная точка не готова, используйте заглушку. useMocks можно сделать переменной среды в системе непрерывной интеграции. Переключение станет очень удобным!
Внедрение зависимости
Кроме useClass , вы можете использовать:
- useValue для строк, чисел и так далее.
- useFactory для передачи функций.
- InjectionToken для отличных от классов значений.
Полное описание смотрите в документации Angular.
Заключение
Внедрение зависимостей Angular — мощный инструмент, используемый для разных задач:
- Прототипирование.
- Переключатели возможностей приложений.
- Заглушки сервисов для тестов.
- Конфигурирование.
Освоение этого инструмента улучшит архитектуру приложений и позволит использовать шаблоны проектирования там, где это казалось невозможным.
