0. sergey_garin 176 15.03.19 12:02 Сейчас в теме

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

Разбираемся, что такое mock-сервисы и зачем они нужны.
На основании реального веб-сервиса создадим сервис-заглушку в SoupUI, посмотрим как его запускать из консоли и напишем сценарий в Vanessa-ADD.

Перейти к публикации

Лучшие комментарии
1. Vladimir Litvinenko 1741 15.03.19 15:02 Сейчас в теме
Спасибо! Шикарная возможность SoapUI рассмотрена, да ещё и в связке с Ванессой.

SoapUI можно кстати хорошо в общий тестовый пайплайн встроить при тестировании в обратном направлении - проверке работоспособности SOAP- или HTTP-сервисов опубликованных из 1С. Правда публикация отчетности возможна только в формате JUnit в то время как от Ванессы лучше получать отчетность в Allure.

На одном из этапов сборочной линии из командной строки можно вызывать выполнение тест-кейса или тест-сьюта вроде такого:

cd /D C:\Program Files\SmartBear\SoapUI-5.5.0\bin\.
cmd.exe /C testrunner.bat -s"<TestSuiteName>" -r -a -j -J -f"<JUnitOutputPath>" -I -i "<PathToSoapProjectXMLFile>"

А потом в пайплайне вызывать генерацию отчета из xml-файлов в формате JUnit. В результате выполнения пайплайна будем иметь два отчета. Один в виде JUnit о тестировании наших веб-сервисов, а другой Allure о выполнении дымовых и функциональных сценарных тестов. Например в Jenkins команда публикации выглядит так:

junit allowEmptyResults: true, testResults: '<JUnitOutputPath>/*.xml'


В целом при использовании Jenkins должно получиться что-то типа такого:
   stages {

        stage('Выполнение тестов SOAP') {

            steps {

                timestamps {

                     cmd "rmdir /S /Q JUnitResults"
                     cmd "cmd.exe /C testrunner.bat -s\"<TestSuiteName1>\" -c\"<TestCaseName1>\" -r -j -J -fJUnitResults -I -S -i \"<PathToSoapProjectXMLFile>\"" 
                     cmd "cmd.exe /C testrunner.bat -s\"<TestSuiteName2>\" -c\"<TestCaseName2>\" -r -j -J -fJUnitResults -I -S -i \"<PathToSoapProjectXMLFile>\""

                }             
            }
        }

        stage('Публикация отчета JUnit') {

            steps {

                timestamps {
                    junit allowEmptyResults: true, testResults: 'JUnitResults/*.xml'
                }
                
            }
        }

Показать


Дополнив это материалами этой публикации, получается, что с помощью SoapUI мы можем покрывать функционал как исходящих (на моки), так и входящих вызовов.


P.S.: К слову, есть большой полюс связки SoapUI и Jenkins. В обоих инструментах используется Groovy для создания скриптов и оба работают на JVM. Переключаться между контекстами легко.
CSiER; karnilaev; sergey_garin; fancy; ArchLord42; YPermitin; vikad; +7 Ответить
Остальные комментарии
Избранное Подписка Сортировка: Древо
1. Vladimir Litvinenko 1741 15.03.19 15:02 Сейчас в теме
Спасибо! Шикарная возможность SoapUI рассмотрена, да ещё и в связке с Ванессой.

SoapUI можно кстати хорошо в общий тестовый пайплайн встроить при тестировании в обратном направлении - проверке работоспособности SOAP- или HTTP-сервисов опубликованных из 1С. Правда публикация отчетности возможна только в формате JUnit в то время как от Ванессы лучше получать отчетность в Allure.

На одном из этапов сборочной линии из командной строки можно вызывать выполнение тест-кейса или тест-сьюта вроде такого:

cd /D C:\Program Files\SmartBear\SoapUI-5.5.0\bin\.
cmd.exe /C testrunner.bat -s"<TestSuiteName>" -r -a -j -J -f"<JUnitOutputPath>" -I -i "<PathToSoapProjectXMLFile>"

А потом в пайплайне вызывать генерацию отчета из xml-файлов в формате JUnit. В результате выполнения пайплайна будем иметь два отчета. Один в виде JUnit о тестировании наших веб-сервисов, а другой Allure о выполнении дымовых и функциональных сценарных тестов. Например в Jenkins команда публикации выглядит так:

junit allowEmptyResults: true, testResults: '<JUnitOutputPath>/*.xml'


В целом при использовании Jenkins должно получиться что-то типа такого:
   stages {

        stage('Выполнение тестов SOAP') {

            steps {

                timestamps {

                     cmd "rmdir /S /Q JUnitResults"
                     cmd "cmd.exe /C testrunner.bat -s\"<TestSuiteName1>\" -c\"<TestCaseName1>\" -r -j -J -fJUnitResults -I -S -i \"<PathToSoapProjectXMLFile>\"" 
                     cmd "cmd.exe /C testrunner.bat -s\"<TestSuiteName2>\" -c\"<TestCaseName2>\" -r -j -J -fJUnitResults -I -S -i \"<PathToSoapProjectXMLFile>\""

                }             
            }
        }

        stage('Публикация отчета JUnit') {

            steps {

                timestamps {
                    junit allowEmptyResults: true, testResults: 'JUnitResults/*.xml'
                }
                
            }
        }

Показать


Дополнив это материалами этой публикации, получается, что с помощью SoapUI мы можем покрывать функционал как исходящих (на моки), так и входящих вызовов.


P.S.: К слову, есть большой полюс связки SoapUI и Jenkins. В обоих инструментах используется Groovy для создания скриптов и оба работают на JVM. Переключаться между контекстами легко.
CSiER; karnilaev; sergey_garin; fancy; ArchLord42; YPermitin; vikad; +7 Ответить
3. ArchLord42 69 15.03.19 18:03 Сейчас в теме
(1)
проверке работоспособности SOAP- или HTTP-сервисов опубликованных из 1С


А почему бы не тестировать сервисы нативно?)
т.е. код выносим в модули, а там уже обычными тестами покрываем, имхо так гораздо удобней и быстрей выходит.

Вот пример с HTTP сервисом:

Есть метод "ОчередиExtGET" (см скрин)

Чтобы его покрыть тестом, надо всего навсего вызвать метод из модуля, где параметр метода "Запрос" будет обработкой, эмулирующий объект "HTTPСервисЗапрос"
Прикрепленные файлы:
4. Vladimir Litvinenko 1741 15.03.19 21:59 Сейчас в теме
(3) Если обычные тесты - это юнит-тесты на основе xUnitFor1C (теперь в составе Vanessa-ADD), то конечно можно и так. В этом случае не придётся изобретать свой формат отчетности и логов.

Удобно чтобы механизм позволял удобно отображать отчетность о результатах всех проверок в одном месте. Например на странице конкретной сборки в веб-интерфейсе CI-сервера, где фиксируются все этапы проверок и их результаты (артефакты и все отчёты). Так быстрее пройтись по цепочке от сообщения об ошибке к выявлению её причины. Да и в целом визуальная информация, собранная в одном месте, лучше воспринимается.

У SoapUI есть ещё такое преимущество как распространенность среди QA-инженеров веб-программистов. То есть созданными тест-кейсами можно будет поделиться с теми, кто наиболее вероятно будет писать и проверять клиентов для наших сервисов.

И ещё это внешний по отношению к тестируемой системе инструмент. Если мы хотим провести не только модульный, но интеграционный тест, убедиться в том, что сервис нормально публикуется и отвечает на внешние запросы, то в этом случае внешний инструмент даст более объективную информацию.
2. YPermitin 3273 15.03.19 15:22 Сейчас в теме
(0) Отличная статья!

Спасибо автору за труды!
5. Кадош 16.03.19 08:20 Сейчас в теме
6. vlad.frost 185 16.03.19 14:35 Сейчас в теме
Пока в публичном доступе готового решения для Windows не найдено, остановимся на простом варианте — будем завершать работу процесса java.exe командой

Долго мучался с этой проблемой. В итоге решил с помощью Jenkins: отдельным шагом пайплайна запускаю java-процесс с помощью команды START. Мок запускается в отдельном окне и по окончании работы пайплайна Jenkins его сам прибивает.
Scorpion4eg; karnilaev; sergey_garin; Vladimir Litvinenko; +4 Ответить
7. sergey_garin 176 18.03.19 08:48 Сейчас в теме
(6) Хорошая идея. Получается, в начале пайплайна поднять все моки, которые будут использоваться в тестах?
А всегда ли это будет удобно?
Например, на моем текущем проекте используется около 40 веб-сервисов: описания моков сохранены в отдельные файлы и про прогоне тестов моки по очереди поднимаются и опускаются (правда, немного не так, как описано в статье, но суть такая же). И получается, что во время прохождения отдельного сценария поднят только тот мок, который нужен сейчас.
11. kuzyara 774 26.06.19 04:43 Сейчас в теме
(6)
C:\soapui.net\bin>StandardConsoleApp.exe /?
start [/F Filepath] [/S Filepath] [/T:timeout]
/F                   Set XML SoapUI Project, by default using "project.xml" in root directory.
Filepath             Full filepath.
/S                   Set stop file if need to shut down server by file.
Filepath             Full filepath.
/T:timeout           Timeout in seconds if need to shut down server by timeout.

только тссс...
8. artbear 1143 21.03.19 12:14 Сейчас в теме
(0) Отличная статья, полезнейшие кейсы, детально расшифрованные.
9. artbear 1143 21.03.19 12:26 Сейчас в теме
(0) по поводу шага "Я выполняю команду "

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


1 ты почему-то посмотрел код метода из модуля объекта bddRunner, который выполняется на толстом клиенте в обычных формах.
Это устаревший код :)

Если посмотришь код этого же метода из упр.формы bddRunner, ты увидишь там нормальный код

&НаКлиенте
Функция ВыполнитьКомандуОСБезПоказаЧерногоОкна(Знач ТекстКоманды, Знач ЖдатьОкончания = Истина,
	Знач ИспользоватьКодировкуТекстаUTF8 = Истина) Экспорт

	УправлениеПриложениями = Плагин("УправлениеПриложениями");
	Возврат УправлениеПриложениями.ВыполнитьКомандуОСБезПоказаЧерногоОкна(ТекстКоманды, ЖдатьОкончания,
		ИспользоватьКодировкуТекстаUTF8);

КонецФункции
Показать


в плагине "УправлениеПриложениями" передача параметров уже давно доработана.
и в т.ч. и для толстого клиента обычного приложения, и для сервера также :)

2 У шага "Я выполняю команду " свое назначение - он выполняет именно команду и ждет ее завершения.

у тебя другой кейс - запустить процесс на выполнение и не ждать его выполнения.

Этот кейс возможно также решить с помощью плагина "УправлениеПриложениями"

- например, сделать доп.шаг - я запускаю процесс "какая строка запуска" на выполнение и сохраняю его идентификатор как переменную "ИдПроцесса"
- реализация шага проста.
- также можно сделать доп.шаг для запуска на сервере - я запускаю на сервере процесс "какая строка запуска" на выполнение и сохраняю его идентификатор как переменную "ИдПроцесса"
10. s_vidyakin 61 25.06.19 12:19 Сейчас в теме
Когда пробовал писать скрипты на SoapUI понял что проще развернуть тестовый веб-сервис на копии базы и написать обработку тестирования, чем тыкаться в бесполезную справку SoapUI и городить моки. Там нигде не описано как писать на Groovy в контексте вызовов и ответов, как передавать данные между несколькими вызовами и обрабатывать между вызовами. Только один абзац по передаче переменной между сессиями и всё. Где вы брали инфу по вот этому всему - "GroovyUtils(context)" и т.д?
Если веб-сервис внешний и у нас нет контроля бэкэнда то да, локальные моки это тема. А если есть под рукой база, то зачем?
12. berezdetsky 421 26.06.19 09:04 Сейчас в теме
(0) Если запускать процесс не через WScript.Shell, а через WMI - можно получать в ответ конкретный PID запущенного процесса.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Программист 1С
Москва
зарплата от 120 000 руб.
Полный день

Руководитель проекта, аналитик, консультант
Санкт-Петербург
По совместительству

Программист 1С
Самара
зарплата от 100 000 руб. до 150 000 руб.
Полный день

Программист 1С
Тюмень
зарплата от 65 000 руб.
Полный день