Что такое заглушка в программировании
Тестирование компонента заключается в подаче входных данных в его интерфейс, ожидании ответа компонента и проверки полученных результатов. В процессе работы компоненты часто пользуются другими компонентами, передают им данные и используют полученную от них информацию:
Рисунок 1: Тестирование реализованного компонента
Эти другие компоненты могут вызывать сложности при тестировании:
Рисунок 2: Тестирование компонента с заглушкой вместо компонента, от которого он зависит
У заглушек есть два недостатка.
Заглушки и практика разработки программного обеспечения
Иногда заглушки создаются только потому, что реальный компонент еще не доступен на момент тестирования. Во всех остальных случаях заглушки следует сохранять после завершения разработки. Скорее всего, тесты, поддерживаемые заглушками, будут важны при обслуживании продукта. Поэтому качество заглушек должно быть выше, чем качество кода на выброс. Хотя к качеству заглушек не предъявляются настолько жесткие требования, как к коду продукта (например, большинство заглушек не нуждается в собственных тестах), в дальнейшем некоторые из них придется обслуживать в процессе изменения продукта. Если обслуживание будет требовать слишком больших усилий, заглушки будут выброшены, и инвестиции в них будут потеряны.
И хотя вряд ли вы будете пользоваться операторами SQL для всех операций чтения и записи значений, почти наверняка операторы SQL будут, по крайней мере, в нескольких методах. Например, компонент, нуждающийся в значении, может вызывать следующий метод:
Сценарий 2: в целях тестирования база данных заменена заглушкой. Код компонента должен быть независим от того, с чем он работает: с реальной базой данных или с заглушкой. Поэтому в коде должны применяться методы абстрактного интерфейса:
В тестах пары из ключей и значений KeyValuePairs будут реализованы с помощью какой-нибудь простой конструкции, например таблицы:
За исключением периода тестирования, компонент будет пользоваться адаптером, преобразующим вызовы KeyValuePairs в операторы SQL:
Дополнительная информация
© Copyright IBM Corp. 1987, 2006. Все права защищены..
Что означает «заглушить» в программировании?
например, что это означает в этой цитате?
интеграция с внешним API является почти гарантией в любом современном веб-приложении. Чтобы эффективно протестировать такую интеграцию, вам нужно заглушки его. Хороший заглушки должно быть легко создавать и последовательно обновляться с фактическими, текущими ответами API. В этом посте мы изложим стратегию тестирования, используя заглушки для внешнего API.
6 ответов
заглушка является управляемой заменой для Существующих Зависимостей (или коллаборационист) в системе. Используя заглушку, вы можете проверить свой код без борьбы с зависимостью напрямую.
Внешняя Зависимость-Существующая Зависимость:
Это объект в вашей системе, который ваш код под тестом взаимодействует и над которым у вас нет контроля. (Общий примерами являются файловые системы, потоки, память, время и так далее.)
Например в приведенном ниже коде:
вы хотите проверить mailService.Отправка электронных писем отключена() метод, но для этого вам нужно смоделировать исключение в вашем методе тестирования, так что вам просто нужно создать поддельный заглушка errorService объект для имитации результата, который вы хотите, тогда ваш тестовый код сможет протестировать mailService.Отправка электронных писем отключена() метод. Как вы видите, вам нужно смоделировать результат, который из другой зависимости, которая ErrorService объект класса (существующий объект зависимости).
A заглушки, в этом контексте, означает макет реализации.
то есть простая, поддельная реализация, которая соответствует интерфейсу и должна использоваться для тестирования.
термины непрофессионала, это фиктивные данные (или поддельные данные, тестовые данные. так далее.) который можно использовать для тестирования или разработки кода до тех пор, пока вы (или другая сторона) не будете готовы представить/получить реальные данные. Это программистский «Lorem Ipsum».
макет очень специфический и ограничительный вид заглушки, потому что макет-это замена другой функции или объекта для тестирования. На практике мы часто используем mocks в качестве локальных программ (функций или объектов) для замены удаленной программы в тестовой среде. В любом случае макет может имитировать фактическое поведение замененной программы в ограниченном контексте.
самые известные виды заглушек очевидно для распределенного программирования, когда вызывать удаленные процедуры (RPC) или удаленные объекты (RMI, описание). Большинство распределенных программных фреймворков / библиотек автоматизируют генерацию заглушек, так что вам не нужно писать их вручную. Заглушки могут быть сгенерированы из определения интерфейса, написанного с помощью IDL например (но вы также можете использовать любой язык определения интерфейсов).
типично, в RPC, RMI, CORBA, и так далее, одно различает заглушки на стороне клиента, которые в основном заботятся о маршалинге / сериализации аргументов и выполнении удаленного вызова, и серверные стабы, которые в основном заботятся о unmarshaling / десериализации аргументов и фактически выполняют удаленную функцию/метод. Очевидно, что клиентские заглушки расположены на стороне клиента, в то время как заглушки sever (часто называемые скелетами) расположены на стороне сервера.
написание хороших эффективных и общих заглушек становится довольно сложным при работе со ссылками на объекты. Большинство фреймворков распределенных объектов, таких как RMI и CORBA, имеют дело со ссылками на распределенные объекты, но большинство программистов избегают этого, например, в средах REST. Как правило, в средах REST программисты JavaScript делают простые функции заглушки для инкапсуляции вызовов AJAX (сериализация объектов поддерживается JSON.parse и JSON.stringify ). The Swagger Codegen проект обеспечивает обширное поддержка автоматического создания заглушек REST на разных языках.
заглушка-это определение функции, которое имеет правильное имя функции, правильное количество параметров и выдает фиктивный результат правильного типа.
Это помогает написать тест и служит своего рода лесов, чтобы сделать возможным запустить примеры еще до завершения проектирования функции
Использование заглушек для изоляции частей приложений друг от друга при модульном тестировании
Типы заглушек — это одна из двух технологий, которые платформа Microsoft Fakes предоставляет для более простого изолирования тестируемого компонента от других вызываемых компонентов. Заглушка — это небольшая часть кода, которая заменяет собой другой компонент во время тестирования. Преимущество использования заглушки заключается в том, что она возвращает последовательные результаты, упрощая написание теста. Тесты можно выполнять, даже если другие компоненты пока не работают.
Обзор и рекомендации по быстрому началу работы с Fakes см. в статье Изоляция тестируемого кода с помощью Microsoft Fakes.
Для использования заглушек необходимо написать компонент таким образом, чтобы он использовал только интерфейсы, а не классы для ссылки на другие части приложения. Это рекомендуемая практика разработки, поскольку при внесении изменений в одну часть, скорее всего, не потребуется вносить изменения в другую. При тестировании это позволяет заменить заглушку на реальный компонент.
На схеме представлен компонент StockAnalyzer, который требуется протестировать. Обычно он использует другой компонент — RealStockFeed. Но RealStockFeed возвращает различные результаты при каждом вызове его методов, что усложняет тестирование StockAnalyzer. Во время тестирования мы заменяем этот компонент на другой класс — StubStockFeed.
Поскольку предполагается, что заглушки могут структурировать код таким образом, они обычно используются для изолирования одной части приложения от другой. Для изолирования ее от других сборок, которыми вы не можете управлять, например System.dll, обычно используются оболочки. См. статью Использование оболочек совместимости для изоляции приложения от других сборок при модульном тестировании.
Использование заглушек
Разработка для внедрения зависимости
Для использования заглушек приложение должно быть разработано таким образом, чтобы различные компоненты не зависели друг от друга, а только от определений интерфейса. Вместо соединения во время компиляции компоненты соединяются во время выполнения. Этот шаблон позволяет создать надежное и легко обновляемое программное обеспечение, поскольку изменения, как правило, не выходят за границы компонентов. Им рекомендуется пользоваться, даже если вы не используете заглушки. При написании нового кода легко использовать шаблон внедрения зависимости. При написании тестов для существующего программного обеспечения может потребоваться выполнить его рефакторинг. Если это непрактично, можно рассмотреть возможность использования оболочек.
Начнем с показательного примера, представленного на схеме. Класс StockAnalyzer считывает курсы акций и выдает некоторые интересные результаты. Он имеет несколько открытых методов, которые требуется протестировать. Для простоты рассмотрим только один из этих методов, который сообщает текущий курс определенной акции. Требуется написать модульный тест этого метода. Вот первый вариант теста.
Одна проблема с данным тестом немедленно бросается в глаза: курсы акции различаются, поэтому утверждение обычно будет выдавать ошибку.
Другая проблема может заключаться в том, что компонент StockFeed, который используется классом StockAnalyzer, в данный момент находится в разработке. Вот первый вариант кода тестируемого метода.
В таком виде этот метод может не компилироваться или может вызвать исключение, поскольку работа над классом StockFeed еще не завершена. Внедрение интерфейса позволит решить обе эти проблемы. При внедрении интерфейса применяется следующее правило:
«Компонент» означает класс или группу классов, которые разрабатываются и обновляются вместе. Обычно компонент — это код в одном проекте Visual Studio. Отделять классы в одном компоненте не так важно, поскольку они обновляются одновременно.
Также не имеет особого значения отделять компоненты от классов относительно стабильной платформы, например System.dll. Если написать интерфейсы для всех этих классов, код будет перегружен.
Вы можете отделить код StockAnalyzer от StockFeed с помощью интерфейса следующим образом:
В этом примере классу StockAnalyzer передается реализация IStockFeed при построении. В готовом приложении код инициализации выполнил бы следующее подключение.
Существуют более гибкие способы выполнения этого подключения. Например, StockAnalyzer может принять объект фабрики, который может создать экземпляры различных реализаций IStockFeed в различных условиях.
Создание заглушек
Вы отделили класс, который необходимо протестировать, от других используемых им компонентов. Такое отделение позволяет не только сделать приложение более надежным и гибким, но и подключить тестируемый компонент к реализациям заглушки интерфейсов для тестирования.
Достаточно написать заглушки как классы обычным способом. Однако Microsoft Fakes предлагает более динамический способ создания наиболее подходящей заглушки для каждого теста.
Чтобы использовать заглушки, необходимо сначала создать типы заглушек из определений интерфейса.
Добавление сборки Fakes
В Обозревателе решений выполните следующие действия:
Выделите сборку, содержащую определения классов, для которых необходимо создать оболочки. Например, если требуется создать оболочку для DateTime, выберите System.dll.
В контекстном меню щелкните Добавить сборку имитаций.
Создание теста с заглушками
Заглушки также создаются для методов получения и задания свойств, для событий и для универсальных методов.
Проверка значений параметров
Можно проверить, что компонент передает правильные значения, когда вызывает другой компонент. Можно поместить утверждение в заглушку или сохранить значение и проверить его в основной части теста. Пример:
Заглушки для различных видов членов типа
Методы
Если не предоставить заглушку для функции, Fakes создает функцию, возвращающую значение по умолчанию возвращаемого типа. Для чисел значением по умолчанию является 0, а для типов классов — null (C#) или Nothing (Visual Basic).
Свойства
Если не предоставить методы-заглушки для метода получения или задания свойства, Fakes создает заглушку, хранящую значения, чтобы свойство заглушки выступало в роли простой переменной.
События
События представляются как поля делегата. В результате любые события, замененные заглушками, могут вызываться путем вызова резервного поля события. Рассмотрим следующий интерфейс, который требуется заменить заглушкой.
Универсальные методы
Чтобы заменить универсальные методы заглушками, предоставьте делегат для каждого требуемого экземпляра метода. Например, рассмотрим следующий интерфейс, содержащий универсальный метод.
Можно написать тест, в котором экземпляр GetValue заменяется заглушкой:
Если бы код вызвал GetValue с любым другим экземпляром, то заглушка просто вызвала бы поведение.
Заглушки виртуальных классов
В предыдущих примерах заглушки создавались из интерфейсов. Заглушки также можно создавать из класса с виртуальными или абстрактными членами. Пример:
Заглушки отладки
Типы заглушек призваны обеспечить бесперебойную отладку. По умолчанию отладчик должен обходить любой создаваемый код, чтобы сразу переходить к пользовательским реализациям членов, которые присоединены к заглушке.
Ограничения заглушки
Сигнатуры методов с указателями не поддерживаются.
Запечатанные классы или статические методы не могут быть заменены заглушками, поскольку типы заглушек зависят от диспетчеризации виртуальных методов. В таких случаях используйте типы оболочек, которые описываются в статье Использование оболочек совместимости для изоляции приложения от других сборок при модульном тестировании.
Изменение поведения заглушек по умолчанию
Заглушки для веб-сервисов
Приложения 1С редко работают в изоляции — чаще всего они интегрируются с различными сервисами, которые могут быть расположены как в локальной сети предприятия, так и на удаленных серверах. И иногда встает вопрос тестирования этой интеграции в рамках общего сценарного тестирования. Посмотрим, с какими проблемами при этом можно столкнуться и при чем тут вообще эти самые «заглушки».
Содержание
С чем будем работать
Давайте предположим, что мы ведем разработку функционала, который обращается к удаленному веб-сервису, получает из него данные и запускает в базе 1С механизм расчетов. Не важно какие именно данные возвращает сервис: важно, то, что полученный результат прямо влияет на работу наших алгоритмов.
Предположим, что веб-сервис отвечает на запросы с ощутимым задержками, потому что обращается в нагруженную базу данных в реальном времени. При этом он расположен в VPN-сети и физическое его нахождение нам неизвестно: сервер может находиться в соседнем здании, может быть поднят в облаке или физически располагаться в зарубежном дата-центре.
В целом, используется стандартная схема: 1С обращается к сервису, который опубликован на веб-сервере; веб-сервис обращается к базе данных и возвращает результат.
Мы уже используем сценарное тестирование и хотим, чтобы наши тесты работали стабильно и не зависели от доступности удаленного сервера, загруженности серверного оборудования или от неполадок в сети. Поскольку прогон тестов — процесс не однократный, а регулярный (и в целом автоматический), мы хотим сделать так, чтобы в момент запуска тестов веб-сервис был всегда доступен и работал максимально быстро, стабильно и предсказуемо.
Обратите внимание, что мы не собираемся проверять работоспособность веб-сервиса и заниматься его тестированием — этим занимаются разработчики веб-сервиса. Нам нужно обеспечить его бесперебойную работу на момент проведения тестирования.
Получается, нам нужна такая «локальная копия» удаленного сервиса, которую можно настроить нужным нам образом, а своему приложению сказать: «Во время тестирования не ходи на удаленный сервер, а ходи на localhost».
Проблемы тестирования интеграции
Вообще, для использования заглушек веб-сервисов может быть много причин. Например, следующих:
Тесты замедляются. Если поставщик сервиса находится далеко, сетевая среда нестабильная и при вызове сервиса происходит задержка, то время прохождения тестов может значительно увеличиваться.
Тесты работают нестабильно. Веб-сервисы могут быть не всегда доступны из-за технических обновлений, подвержены перегрузкам или ошибкам сетевых протоколов.
Тесты покрывают не все возможные варианты ответов сервиса. Не всегда есть возможность получить некоторые ответы от реального веб-сервиса и промоделировать все рабочие ситуации — следовательно, максимально полно протестировать взаимодействие.
Доступ к рабочим веб-сервисам ограничен. Часто встречается ситуация, когда рабочие сервисы недоступны из тестового контура, в котором программисты ведут разработку. Это делает как по причине безопасности, так и для того, чтобы не подвергать лишней нагрузке рабочее окружение.
Из-за ошибок разработчика могут быть подвергнуты риску реальные данные. Например, есть веб-сервисы, которые позволяют добавлять или изменять данные в удаленной системе. Ошибка при вызове такого сервиса может привести к потере данных.
Давайте теперь поближе рассмотрим мок-объекты.
Заглушки
Существует несколько видов объектов, которые позволяют симулировать поведение реальных объектов во время тестирования:
Относительно веб-сервисов можно сказать, что мок-сервис позволяет переопределить реальный сервис и подставить вместо него упрощенную реализацию, которая работает нужным разработчику образом и дает доступ к собственным данным и настройкам. Мы как бы создаем у себя аналог удаленного веб-сервиса, который отвечает на вызовы нашего приложения.
Правда, тут возникают две сложности.
Во-первых, моки надо создать. Надо устанавливать дополнительный софт, описывать логику, загружать нужные данные в макет ответа. Не то чтобы это сложно, но это требует усилий и времени. Может быть, кому-то будет проще сохранить результат вызова в файл и при тестировании обращаться не к заглушке, а к файлу. В небольших проектах с малым количеством тестов такой подход вполне оправдан.
Во-вторых, веб-сервис может поменяться. Например, программист написал рабочую логику для заглушки, а через какое-то время веб-сервис стал работать по-другому (а разработчика, как часто бывает, об этом никто не уведомил). О том, что в работе веб-сервиса что-то поменялось он узнал, когда выкатил обновление на рабочую базу.
Решение простое — для сервиса, который может быть подвержен изменениям нужно сделать набор дымовых тестов (smoke-тесты). Дымовые тесты проверяют, что основные методы сервиса не изменились и обращение к ним не вызывает ошибок.
Мы рассмотрим способ создания мок-сервисов в программе SoapUI, которая является достаточно популярной в мире тестирования. Первоначальная схема работы примет такой вид:
Тестируемое приложение 1С больше не будет обращаться к удаленному сервису, а получит тот ответ, который мы заранее подготовили и опубликовали из SoapUI.
Запускаем моки через SoapUI
Шаг 0. Готовим окружение
Программа SoapUI (подробнее о ней можно прочитать в публикации Использование SoapUi для работы с веб-сервисами. Часть1) позволяет на основании WSDL-схемы сервиса создать Mock-service и опубликовать его на собственном веб-сервере, который умеет запускать.
SoapUI можно получить на официальном сайте компании SmartBear. Для наших целей достаточно бесплатной 32х-разрядной OpenSource версии — ее нужно скачать и установить.
В конфигурации 1С, которую мы дорабатываем, есть обработка Расчет трафика — она обращается к веб-сервису CalculateService и вызывает метод CalculateTraffic, в который передает несколько параметров, вроде ID, StoreID и других. Рассчитанный веб-сервисом результат записывается в регистр и запускает внутренний механизм расчетов (что он именно делает, в рамках статьи значения не имеет).
Мы дорабатываем механизм расчетов и во время проведения тестов хотим вместо ответов удаленного сервиса подставлять свои заранее заготовленные варианты.
! Поскольку я воспроизвожу пример для статьи на своем компьютере, в адресе вы видите «localhost». Но подразумевается, что в рабочей ситуации мы будем обращаться к рабочему сервису на рабочем сервере.
Для начала запустим браузер и убедимся, что веб-сервис доступен:
Дальше добавим веб-сервис в SoapUI и сделаем для него заглушку.
Шаг 1. Импортируем WSDL-схему
Запустим SoapUI и создадим новый проект.
Если при импорте возникает ошибка, дело скорее всего в авторизации: нужно ввести имя пользователя и пароль.
Забегая немного вперед, добавлю, что в SoapUI есть удобный способ сохранить данные авторизации: нужно заполнить параметры Username и Password на вкладке Auth, которая станет доступна в редакторе запроса к сервису:
В дереве проекта появился веб-сервис CalculateService.
Теперь мы можем заполнить параметры и обратиться к сервису:
Шаг 2. Запускаем mock-сервис
Задаем параметры MockService:
Обратите внимание на порт, на котором будет доступен сервис и на путь к нему.
Жмем ОК и заполняем имя мок-сервиса:
Открывается окно, из которого можно запустить мок-сервис и указать его настройки:
Зайдем в настройки и укажем, что мок будет подниматься на локальном интерфейсе localhost:
Жмем на Запуск. Если запуск пройдет успешно, станет доступна кнопка Открыть WSDL-схему в браузере:
В дереве проекта появился мок-сервис MoskCalculateService с методом CalculateTraffic:
Шаг 3. Настраиваем ответ
Открываем редактор ответа Response 1. В этой форме можно определить данные, которые будет возвращать наш мок-сервис.
Здесь можно заполнить значения полей ответа, подставить любую валидную XML или написать скрипт на Groovy, который будет определять содержание ответа в зависимости от запроса к сервису. Например, мы можем в получать в скрипте значения переданных параметров, считывать файлы с диска и возвращать их клиенту с результатом вызова, при это логгируя все входящие запросы.
Я покажу простой вариант: получаем из входящего запроса значения параметров StoreID и Offset, сам запрос сохраняем на диск, а клиенту возвращаем значение, рассчитанное по формуле Offset*24 + StoreID:
Я сохранил проект в d:\BASE1C\DEMO\MockCalculateService.xml
Запускаем проект SoapUI из консоли
Для того чтобы поднять мок-сервис из командной строки (а, следовательно, иметь возможность сделать это программным образом), нужно выполнить файл mockservicerunner.bat из директории C:\Program Files (x86)\SmartBear\SoapUI-5.5.0\bin.
Подробное описание параметров запуска mockservicerunner.bat можно найти на странице сайте SoapUI или в консоли:
Главный обязательный параметр — путь к xml-файлу с проектом из SoapUI. Программа считывает настройки проекта из файла и по умолчанию поднимает все мок-сервисы, которые в нем описаны.
Открываем консоль в папке c:\Program Files (x86)\SmartBear\SoapUI-5.5.0\bin\ и запускам наш сервис командной:
В консоли наблюдаем, что MockService started on port 8090:
Подробный лог запуска записывается в c:\Program Files (x86)\SmartBear\SoapUI-5.5.0\bin\soapui.log, а ошибки можно найти в файлах soapui-errors.log и errors.log
При запуске может возникнуть такая ошибка:
2019-03-04 11:30:05,556 ERROR [errorlog] java.lang.ClassNotFoundException: com.eviware.soapui.plugins.auto.factories.AutoImportMethodFactory
Проверим еще раз, что WSDL-схема доступна по адресу http://localhost:8090/MockCalculateService?WSDL.
Теперь мы умеем запускать заглушки с помощью командной строки. Пойдем дальше и попробуем прикрутить все это дело к Ванессе.
Подключаем Ванессу
Поскольку на Инфостарте уже есть замечательные статьи про тестирование и применение Ванессы на практике, сразу перехожу к делу.
План такой: при запуске теста будем поднимать наш мок-сервис, проверять его доступность, заполнять поля на форме и нажатие на кнопку Рассчитать выызвать его метод CalculateTraffic.
Определим примерный набросок сценария:
Поднимаем сервис из файла;
Проверяем, что сервис доступен;
Заполняем параметры на форме обработки;
Выполняем вызов процедуры, которая обращается к сервису;
Проверяем результат расчета;
Завершаем работу мок-сервиса.
Создадим файл ПроверкаСервиса.feature (я взял за основу одну из своих существующих фич) и загрузим его в Ванессу:
Дальше мы будем заниматься реализацией шагов. Итоговый текст фичи будет приведен в конце.
Подготовка данных
Пара слов о том, как будем хранить настройки для обращений к веб-сервисам.
Полный путь к файлу mockservicerunner.bat записываем в константу ПутьКЗапускателюЗаглушекВебСервисов, а для описаний веб-сервисов добавим справочник ВебСервисы:
При выполнении сценария каждый раз будем заполнять константу:
И добавлять новый элемент в справочник Веб-сервисы:
Делаем это потому, что другой тест или пользователь может перезаписать или удалить наши значения — то есть нет гарантии, что во время тесты в них будут заполнены правильном образом.
Элемент справочника будем загружать из макета. Так удобнее, чем генерировать заполнение полей через кнопко-нажималку.
В сгенерированной Ванессой обработке (этап генерации обработки я опускаю, подразумевая, что делать это мы умеем) нужно добавить макет и скопировать туда содержимое табличного документа:
Запускаем моки
Для запуска моков нам нужно выполнить батник mockservicerunner.bat с параметром d:\BASE1C\DEMO\MockCalculateService.xml.
Видим, что в стандартной библиотеке Ванессы есть шаг Я Запускаю команду с параметром, который позволяет выполнить команду систему с произвольным набором параметров.
Можно было бы воспользоваться этим шагом, но, как говорится — есть нюансы.
Во-первых, придется каждый раз писать что-то вроде «Я запускаю команду ‘c:\Program Files (x86)\SmartBear\SoapUI-5.5.0\bin\mockservicerunner.bat’ с параметром «d:\BASE1C\DEMO\MyServiceProject.xml» — это длинно и неудобно.
Во-вторых, библиотечный шаг выполняется только в синхронном режиме — то есть вызывающий процесс (в нашем случае это 1С) будет ожидать завершения работы вызываемой команды, чтобы продолжить свое выполнение. Это значит, что 1С запустит мок-сервис и будет висеть, пока он будет запущен. Не совсем то, что нам нужно.
Вот так реализован шаг Я запускаю команду в файле из поставки libraries\Плагины\step_definitions\Фича_УправлениеПриложениями.epf:
А вот реализация функции Выполнить команду ОС без показа черного окна в одной из главных обработок Ванессы bddRunner.epf:
Видно, что вызывается метод Run() объекта WScript.Shell и параметр ЖдатьОкончания вроде бы есть, но передать значения в него нельзя. Баг это или фича, честно говоря, я не понял 
Удобнее всего для запуска моков создать свой шаг, в котором можно принудительно указать параметр метода Run().
Реализуем шаг Я запускаю моки из файла:
Ожидание запуска моков
Чтобы сделать цикличную проверку доступности сервисов, используем функцию ПодключитьОбработчикОжидания и функцию Ванессы ПродолжитьВыполнениеШагов:
Остановка мок-сервисов
После того как тестируемая программа выполнила обращение к мок-сервису, нужно остановить его работу.
При использовании графического интерфейса SoapUI все просто: для остановки мок-сервиса нужно на красную кнопку Stop the mock service.
При запуске через командную консоль тоже проблем нет — достаточно нажать сочетание клавиш Ctrl+C (или Ctrl+Z).
А в случае, когда мы запускаем процесс через WScript.Shell, все несколько сложнее — штатного способа остановить выполнение его нет.
Например, вот вопрос в официальном сообществе SoapUI, который так и остался без ответа: Stop mock service using mockServiceRunner.
Вопрос достаточно распространенный и разработчики предлагают разные решения:
Запоминать PID (идентификатор) процесса и «пристреливать» его после завершения теста. Пример для Linux: Sample script to start/stop soapui mockservicerunner with nohup
Сделать обертку над SoapUI, которая после запуска веб-сервиса будет пытаться прочитать внешний файл-флаг. Если файла нет — все ок, работаем дальше. Если файл появился — завершаем работу сервиса. Проект на гитхабе: Wrapper to start SoapUI MockService Runner
Написать собственное приложение или скрипт, который будет парсить файл проекта SoapUI, извлекать из него описание сервиса и поднимать собственный веб-сервис.
Пока в публичном доступе готового решения для Windows не найдено, остановимся на простом варианте — будем завершать работу процесса java.exe командой
это сработает, если больше нет запущенных процессов java.exe (точнее говоря, они все будут завершены в момент выполнения этой команды).
Или можно использовать более продвинутый вариант:
скрипт завершит работы всех процессов, у которых в параметрах запуска есть название нашего файла с проектом: «MyServiceProject.xml».
Коллеги, если у кого есть более изящное решение, сообщите
Результат
Теперь мы можем составить полный текст нашего сценария «Расчет трафика»: