Заглушки для веб-сервисов

Приложения 1С редко работают в изоляции — чаще всего они интегрируются с различными сервисами, которые могут быть расположены как в локальной сети предприятия, так и на удаленных серверах. И иногда встает вопрос тестирования этой интеграции в рамках общего сценарного тестирования. Посмотрим, с какими проблемами при этом можно столкнуться и при чем тут вообще эти самые «заглушки».

Содержание

С чем будем работать

Проблемы тестирования интеграции

Заглушки

Запускаем моки через SoapUI

Шаг 0. Готовим окружение

Шаг 1. Импортируем WSDL-схему

Шаг 2. Запускаем mock-сервис

Шаг 3. Настраиваем ответ

Запускаем проект SoapUI из консоли

Подключаем Ванессу

Готовим данные

Запускаем моки

Ждем запуска моков

Останавливаем мок-сервис

Результат

С чем будем работать

Давайте предположим, что мы ведем разработку функционала, который обращается к удаленному веб-сервису, получает из него данные и запускает в базе 1С механизм расчетов. Не важно какие именно данные возвращает сервис: важно, то, что полученный результат прямо влияет на работу наших алгоритмов.

Предположим, что веб-сервис отвечает на запросы с ощутимым задержками, потому что обращается в нагруженную базу данных в реальном времени. При этом он расположен в VPN-сети и физическое его нахождение нам неизвестно: сервер может находиться в соседнем здании, может быть поднят в облаке или физически располагаться в зарубежном дата-центре.

В целом, используется стандартная схема: 1С обращается к сервису, который опубликован на веб-сервере; веб-сервис обращается к базе данных и возвращает результат.

Мы уже используем сценарное тестирование и хотим, чтобы наши тесты работали стабильно и не зависели от доступности удаленного сервера, загруженности серверного оборудования или от неполадок в сети. Поскольку прогон тестов — процесс не однократный, а регулярный (и в целом автоматический), мы хотим сделать так, чтобы в момент запуска тестов веб-сервис был всегда доступен и работал максимально быстро, стабильно и предсказуемо.

Обратите внимание, что мы не собираемся проверять работоспособность веб-сервиса и заниматься его тестированием — этим занимаются разработчики веб-сервиса. Нам нужно обеспечить его бесперебойную работу на момент проведения тестирования. 

Получается, нам нужна такая «локальная копия» удаленного сервиса, которую можно настроить нужным нам образом, а своему приложению сказать: «Во время тестирования не ходи на удаленный сервер, а ходи на localhost».

Именно такую задачу — подменять реальный объект или сервис его упрощенной реализацией — и помогают решить так называемые «mock-service» (от англ. mock object: «объект-имитация» или «подставка»). Еще их называют просто «моки» или «заглушки». 

Проблемы тестирования интеграции

Вообще, для использования заглушек веб-сервисов может быть много причин. Например, следующих:

1. Тесты замедляются. Если поставщик сервиса находится далеко, сетевая среда нестабильная и при вызове сервиса происходит задержка, то время прохождения тестов может значительно увеличиваться.

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

3. Тесты покрывают не все возможные варианты ответов сервиса. Не всегда есть возможность получить некоторые ответы от реального веб-сервиса и промоделировать все рабочие ситуации — следовательно, максимально полно протестировать взаимодействие.

4. Доступ к рабочим веб-сервисам ограничен. Часто встречается ситуация, когда рабочие сервисы недоступны из тестового контура, в котором программисты ведут разработку. Это делает как по причине безопасности, так и для того, чтобы не подвергать лишней нагрузке рабочее окружение.

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

Давайте теперь поближе рассмотрим мок-объекты.

Заглушки

«Мок» в программировании — это объект-заглушка, реализующий заданный аспект моделируемого программного окружения.

Существует несколько видов объектов, которые позволяют симулировать поведение реальных объектов во время тестирования: 

1. Dummy — пустые объекты, которые передаются в вызываемые методы, но не используются. Предназначены лишь для заполнения параметров методов.
2. Fake — объекты, которые имеют реализации, но в таком виде, который делает их неподходящими для использования в рабочей ситуации.
3. Stub —  предоставляют заранее заготовленные ответы на вызовы во время теста и не отвечают ни на какие другие вызовы, которые не требуются в тесте. 
4. Mock — объекты, которые заменяют реальный объект в условиях теста и позволяют проверять вызовы своих методов. Содержат заранее подготовленные описания вызовов, которые они ожидают получить. Применяются в основном для тестирования поведения пользователя.

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

Правда, тут возникают две сложности.

Во-первых, моки надо создать. Надо устанавливать дополнительный софт, описывать логику, загружать нужные данные в макет ответа. Не то чтобы это сложно, но это требует усилий и времени. Может быть, кому-то будет проще сохранить результат вызова в файл и при тестировании обращаться не к заглушке, а к файлу. В небольших проектах с малым количеством тестов такой подход вполне оправдан.

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

Решение простое — для сервиса, который может быть подвержен изменениям нужно сделать набор дымовых тестов (smoke-тесты). Дымовые тесты проверяют, что основные методы сервиса не изменились и обращение к ним не вызывает ошибок.

Мы рассмотрим способ создания мок-сервисов в программе SoapUI, которая является достаточно популярной в мире тестирования. Первоначальная схема работы примет такой вид:

Тестируемое приложение 1С больше не будет обращаться к удаленному сервису, а получит тот ответ, который мы заранее подготовили и опубликовали из SoapUI.

Запускаем моки через SoapUI
 

Шаг 0. Готовим окружение

Программа SoapUI (подробнее о ней можно прочитать в публикации Использование SoapUi для работы с веб-сервисами. Часть1) позволяет на основании WSDL-схемы сервиса создать Mock-service и опубликовать его на собственном веб-сервере, который умеет запускать.

SoapUI можно получить на официальном сайте компании SmartBear. Для наших целей достаточно бесплатной 32х-разрядной OpenSource версии — ее нужно скачать и установить.

В конфигурации 1С, которую мы дорабатываем, есть обработка Расчет трафика — она обращается к веб-сервису CalculateService и вызывает метод CalculateTraffic, в который передает несколько параметров, вроде ID, StoreID и других. Рассчитанный веб-сервисом результат записывается в регистр и запускает внутренний механизм расчетов (что он именно делает, в рамках статьи значения не имеет).

Мы дорабатываем механизм расчетов и во время проведения тестов хотим вместо ответов удаленного сервиса подставлять свои заранее заготовленные варианты.

Сервис, к которому мы обращаемся, расположен по адресу http://localhost/DEMO/ws/CalculateService.1cws?wsdl 

! Поскольку я воспроизвожу пример для статьи на своем компьютере, в адресе вы видите «localhost». Но подразумевается, что в рабочей ситуации мы будем обращаться к рабочему сервису на рабочем сервере.

Для начала запустим браузер и убедимся, что веб-сервис доступен:

Дальше добавим веб-сервис в SoapUI и сделаем для него заглушку.

Шаг 1. Импортируем WSDL-схему

Запустим SoapUI и создадим новый проект.

Импортируем в проект описание нашего веб-сервиса: File -> New Soap Project:

Если при импорте возникает ошибка, дело скорее всего в авторизации: нужно ввести имя пользователя и пароль.

Забегая немного вперед, добавлю, что в SoapUI есть удобный способ сохранить данные авторизации: нужно заполнить параметры Username и Password  на вкладке Auth, которая станет доступна в редакторе запроса к сервису:

В дереве проекта появился веб-сервис CalculateService.

Теперь мы можем заполнить параметры и обратиться к сервису:

Шаг 2. Запускаем mock-сервис

Добавляем метод CalculateTraffic в новый мок-сервис: контекстное меню -> Generate Soap MOCK Service:

Задаем параметры MockService:

Обратите внимание на порт, на котором будет доступен сервис и на путь к нему.

Жмем ОК и заполняем имя мок-сервиса:

Открывается окно, из которого можно запустить мок-сервис и указать его настройки:

Зайдем в настройки и укажем, что мок будет подниматься на локальном интерфейсе localhost:

Жмем на Запуск. Если запуск пройдет успешно, станет доступна кнопка Открыть WSDL-схему в браузере:

Проверяем — должна открыться WSDL-схема по адресу http://localhost:8090/MockCalculateService?WSDL.

Теперь имеем:

• реальный сервис на http://localhost/DEMO/ws/CalculateService.1cws?wsdl 
• mock-реализацию на http://localhost:8090/MockCalculateService?WSDL

В дереве проекта появился мок-сервис MoskCalculateService с методом CalculateTraffic:

Шаг 3. Настраиваем ответ

Открываем редактор ответа Response 1. В этой форме можно определить данные, которые будет возвращать наш мок-сервис.

Здесь можно заполнить значения полей ответа, подставить любую валидную XML или написать скрипт на Groovy, который будет определять содержание ответа в зависимости от запроса к сервису. Например, мы можем в получать в скрипте значения переданных параметров, считывать файлы с диска и возвращать их клиенту с результатом вызова, при это логгируя все входящие запросы.

Я покажу простой вариант: получаем из входящего запроса значения параметров StoreID и Offset, сам запрос сохраняем на диск, а клиенту возвращаем значение, рассчитанное по формуле Offset*24 + StoreID:

Сохраняем проект командной Project -> Save project as на диск — этот файл нам понадобится дальше.

Я сохранил проект в d:BASE1CDEMOMockCalculateService.xml

Запускаем проект SoapUI из консоли

Часть дела сделана — наш «заглушечный» веб-сервис запущен и к нему уже можно обращаться из 1С, но поскольку наша главная цель — автоматизировать его запуск, идем дальше.

Для того чтобы поднять мок-сервис из командной строки (а, следовательно, иметь возможность сделать это программным образом), нужно выполнить файл mockservicerunner.bat из директории C:Program Files (x86)SmartBearSoapUI-5.5.0in.

Подробное описание параметров запуска mockservicerunner.bat можно найти на странице сайте SoapUI или в консоли:

Главный обязательный параметр — путь к xml-файлу с проектом из SoapUI. Программа считывает настройки проекта из файла и по умолчанию поднимает все мок-сервисы, которые в нем описаны.

Открываем консоль в папке c:Program Files (x86)SmartBearSoapUI-5.5.0in и запускам наш сервис командной:

c:Program Files (x86)SmartBearSoapUI-5.5.0in>mockservicerunner.bat d:BASE1CDEMOMockCalculateService.xml

В консоли наблюдаем, что MockService started on port 8090:

Подробный лог запуска записывается в c:Program Files (x86)SmartBearSoapUI-5.5.0insoapui.log, а ошибки можно найти в файлах soapui-errors.log и errors.log

Проверим еще раз, что WSDL-схема доступна по адресу http://localhost:8090/MockCalculateService?WSDL.

Теперь мы умеем запускать заглушки с помощью командной строки. Пойдем дальше и попробуем прикрутить все это дело к Ванессе.

Подключаем Ванессу

Поскольку на Инфостарте уже есть замечательные статьи про тестирование и применение Ванессы на практике, сразу перехожу к делу.

План такой: при запуске теста будем поднимать наш мок-сервис, проверять его доступность, заполнять поля на форме и нажатие на кнопку Рассчитать выызвать его метод CalculateTraffic.

ВебСервисСсылка = Справочники.ВебСервисы.НайтиПоНаименованию("MockCalculateService");

ОпределениеСсылки = Новый WSОпределения(ВебСервисСсылка.СсылкаWSDL);

Прокси = Новый WSПрокси(ОпределениеСсылки,
ОпределениеСсылки.Сервисы[0].URIПространстваИмен,
ВебСервисСсылка.ИмяСервиса,
ВебСервисСсылка.ИмяТочкиПодключения,
60);

Результат = Прокси.CalculateTraffic(
Объект.ID,
Объект.StoreID,
Объект.Date,
Объект.Offset,
Объект.LogisticID,
Объект.MainStatus);

Определим примерный набросок сценария:

1. Поднимаем сервис из файла;

2. Проверяем, что сервис доступен;

3. Заполняем параметры на форме обработки;

4. Выполняем вызов процедуры, которая обращается к сервису;

5. Проверяем результат расчета;

6. Завершаем работу мок-сервиса.

Создадим файл ПроверкаСервиса.feature (я взял за основу одну из своих существующих фич) и загрузим его в Ванессу:

Дальше мы будем заниматься реализацией шагов. Итоговый текст фичи будет приведен в конце.

Подготовка данных

Пара слов о том, как будем хранить настройки для обращений к веб-сервисам. 

Полный путь к файлу mockservicerunner.bat записываем в константу ПутьКЗапускателюЗаглушекВебСервисов, а для описаний веб-сервисов добавим справочник ВебСервисы:

При выполнении сценария каждый раз будем заполнять константу:

И добавлять новый элемент в справочник Веб-сервисы:

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

Элемент справочника будем загружать из макета. Так удобнее, чем генерировать заполнение полей через кнопко-нажималку.

Чтобы создать данные для макета идем в Внешние инструменты -> Генератор макетов данных и в колонке «Данные для выгрузки» выбираем наш справочник ВебСервисы:

В сгенерированной Ванессой обработке (этап генерации обработки я опускаю, подразумевая, что делать это мы умеем) нужно добавить макет и скопировать туда содержимое табличного документа:

Запускаем моки

Для запуска моков нам нужно выполнить батник mockservicerunner.bat с параметром d:BASE1CDEMOMockCalculateService.xml.

Посмотрим, можно ли это сделать стандартным шагом. Идем в Библиотеки -> Добавить известный шаг и поищем по строке «выполн»:

Видим, что в стандартной библиотеке Ванессы есть шаг Я Запускаю команду с параметром, который позволяет выполнить команду систему с произвольным набором параметров.

Можно было бы воспользоваться этим шагом, но, как говорится — есть нюансы.

Во-первых, придется каждый раз писать что-то вроде «Я запускаю команду ‘c:Program Files (x86)SmartBearSoapUI-5.5.0inmockservicerunner.bat’ с параметром «d:BASE1CDEMOMyServiceProject.xml» — это длинно и неудобно.

Во-вторых, библиотечный шаг выполняется только в синхронном режиме — то есть вызывающий процесс (в нашем случае это 1С)  будет ожидать завершения работы вызываемой команды, чтобы продолжить свое выполнение. Это значит, что 1С запустит мок-сервис и будет висеть, пока он будет запущен. Не совсем то, что нам нужно.

Вот так реализован шаг Я запускаю команду в файле из поставки librariesПлагиныstep_definitionsФича_УправлениеПриложениями.epf:

А вот реализация функции Выполнить команду ОС без показа черного окна в одной из главных обработок Ванессы bddRunner.epf:

Видно, что вызывается метод Run() объекта WScript.Shell и параметр ЖдатьОкончания вроде бы есть, но передать значения в него нельзя. Баг это или фича, честно говоря, я не понял 🙂 Удобнее всего для запуска моков создать свой шаг, в котором можно принудительно указать параметр метода Run().

Реализуем шаг Я запускаю моки из файла:

&НаКлиенте
Процедура ЯЗапускаюМокиИзФайла(Парам01) Экспорт

ЯЗапускаюМокиИзФайлаНаСервере(Парам01)

КонецПроцедуры

&НаСервере
Процедура ЯЗапускаюМокиИзФайлаНаСервере(ФайлСОписаниемМокСервисов)

ПутьКЗапускателю = Константы.ПутьКЗапускателюЗаглушекВебСервисов.Получить();

Если НЕ ЗначениеЗаполнено(ПутьКЗапускателю) Тогда
ВызватьИсключение "Не заполнена константа ПутьКЗапускателюЗаглушекВебСервисов";
КонецЕсли;

ТекстКоманды = """" + ПутьКЗапускателю + """" """" + ФайлСОписаниемМокСервисов + """";
ИмяВременногоФайлаКоманды = ПолучитьИмяВременногоФайла("bat");
ЗТ = Новый ЗаписьТекста(ИмяВременногоФайлаКоманды, КодировкаТекста.ANSI);
ЗТ.Закрыть();
ЗТ = Новый ЗаписьТекста(ИмяВременногоФайлаКоманды, КодировкаТекста.UTF8, , Истина);
ЗТ.ЗаписатьСтроку("chcp 65001");
ЗТ.ЗаписатьСтроку(ТекстКоманды);
ЗТ.Закрыть();

WshShell = Новый COMОбъект("WScript.Shell");
Рез = WshShell.Run("""" + ИмяВременногоФайлаКоманды + """", 0, 0);
WshShell = Неопределено;

КонецПроцедуры

Ожидание запуска моков

Чтобы понять, что мок-сервис поднялся корректно, нужно к нему обратится. Если он недоступен — подождать немного и попробовать обратиться еще — и так несколько раз. А если он и после 10-й попытки недоступен — значит, что-то пошло не так и тест провален.

Чтобы сделать цикличную проверку доступности сервисов, используем функцию ПодключитьОбработчикОжидания и функцию Ванессы ПродолжитьВыполнениеШагов:

&НаКлиенте
Процедура ЯОжидаюПоднятиеМок_сервиса(Парам01) Экспорт

КонтекстСохраняемый.Вставить("МокСервис", Парам01);
КонтекстСохраняемый.Вставить("НомерПопытки", 1);

Ванесса.ЗапретитьВыполнениеШагов();

ПодключитьОбработчикОжидания("ПроверитьДоступностьМокСервисов", 1);

КонецПроцедуры

&НаКлиенте
Процедура ПроверитьДоступностьМокСервисов() Экспорт

ШагУпал = Ложь;

Если КонтекстСохраняемый.НомерПопытки <= 10 Тогда

КонтекстСохраняемый.НомерПопытки = КонтекстСохраняемый.НомерПопытки + 1;

Если ВебСервисДоступенНаСервере(КонтекстСохраняемый.МокСервис) Тогда
ОтключитьОбработчикОжидания("ПроверитьДоступностьМокСервисов");
Ванесса.ПродолжитьВыполнениеШагов();
КонецЕсли;

Иначе

ОтключитьОбработчикОжидания("ПроверитьДоступностьМокСервисов");
ШагУпал = Истина;
Ванесса.ПродолжитьВыполнениеШагов(ШагУпал);

КонецЕсли;

КонецПроцедуры

Остановка мок-сервисов

После того как тестируемая программа выполнила обращение к мок-сервису, нужно остановить его работу.

При использовании графического интерфейса SoapUI все просто: для остановки мок-сервиса нужно на красную кнопку Stop the mock service.

При запуске через командную консоль тоже проблем нет — достаточно нажать сочетание клавиш Ctrl+C (или Ctrl+Z).

А в случае, когда мы запускаем процесс через WScript.Shell, все несколько сложнее —  штатного способа остановить выполнение его нет.

Например, вот вопрос в официальном сообществе SoapUI, который так и остался без ответа: Stop mock service using mockServiceRunner.

Вопрос достаточно распространенный и разработчики предлагают разные решения:

1. Запоминать PID (идентификатор) процесса и «пристреливать» его после завершения теста. Пример для Linux: Sample script to start/stop soapui mockservicerunner with nohup 

2. Сделать обертку над SoapUI, которая после запуска веб-сервиса будет пытаться прочитать внешний файл-флаг. Если файла нет — все ок, работаем дальше. Если файл появился — завершаем работу сервиса. Проект на гитхабе: Wrapper to start SoapUI MockService Runner

3. Написать собственное приложение или скрипт, который будет парсить файл проекта SoapUI, извлекать из него описание сервиса и поднимать собственный веб-сервис.

Пока в публичном доступе готового решения для Windows не найдено, остановимся на простом варианте — будем завершать работу процесса java.exe командой

 taskkill /FI "IMAGENAME eq java.exe"  /F 

это сработает, если больше нет запущенных процессов java.exe (точнее говоря, они все будут завершены в момент выполнения этой команды).

Или можно использовать более продвинутый вариант:

powershell (Get-WmiObject Win32_Process  -FILTER "Commandline like '%MyServiceProject.xml%'").Terminate()

скрипт завершит работы всех процессов, у которых в параметрах запуска есть название нашего файла с проектом: «MyServiceProject.xml».

Коллеги, если у кого есть более изящное решение, сообщите 🙂

Результат

Теперь мы можем составить полный текст нашего сценария «Расчет трафика»:

#language: ru

Функционал: Расчет трафика

Как программист 1С
Я хочу проверить работу механизма расчета трафика
Чтобы убедиться, что доработки его не поломали

Контекст:

Дано Я запускаю сценарий открытия TestClient или подключаю уже существующий
И Я удаляю все элементы справочника "ВебСервисы"
И Я устанавливаю значение константы "ПутьКЗапускателюЗаглушекВебСервисов" равным "c:Program Files (x86)SmartBearSoapUI-5.5.0inmockservicerunner.bat"
И Я создаю fixtures по макету "ТестовоеОкружение"

Сценарий: Расчет трафика и выполнение расчетов
Когда Я запускаю моки из файла "d:BASE1CDEMOMockCalculateService.xml"
И Я ожидаю поднятие мок-сервиса "MockCalculateService"
Тогда В командном интерфейсе я выбираю 'Тестирование' 'Расчет трафика'
Когда открылось окно 'Расчет траффка'
И в поле 'ID' я ввожу текст '10'
И в поле 'Store ID' я ввожу текст '5'
И в поле 'Date' я ввожу текст '2025-02-01'
И в поле 'Offset' я ввожу текст '2'
И в поле 'Logistic ID' я ввожу текст '2'
И в поле 'Main status' я ввожу текст 'true'
И я нажимаю на кнопку 'Рассчитать'
Тогда элемент формы с именем "Результат" стал равен '1 253'
И я выполняю команду "taskkill" с параметрами '/FI "IMAGENAME eq java.exe" /F'
И Я закрываю окно 'Расчет трафика'

Результатом работы служит пройденный без ошибок сценарий: 

Мы решили поставленную задачу в минимальном варианте, на основании которого можно реализовать уже более сложную логику.