Использование mock при интеграции с внешним API

Публикация № 1449914 28.05.21

Приемы и методы разработки - Тестирование QA

На Infostart Meetup DevOps инженер-программист Андрей Крапивин поделился с коллегами опытом тестирования интеграции с внешним API – показал возможности мокирования и рассмотрел их применение на реальном примере тестирования погодного виджета для конфигурации «Бухгалтерия 3.0».

Тестирование интеграции с API

 

 

Задача интеграции с API встречается очень часто, по популярности она уступает только обмену между базами и выгрузке из Excel.

Есть много разных вариантов API:

  • Есть мастодонты – Google, Яндекс – у них много разных сервисов, с которыми можно интегрироваться. Например, получение переводов, генерация и чтение текстов, прогнозы погоды.

  • Часто приходится интегрироваться с «Почтой России» или OZON.RU – если ваша компания занимается перевозками или отправкой товаров.

  • С Telegram – если надо отправлять или получать данные и писать ботов.

  • И, конечно, наши государственные сервисы: например, ФНС, если вам нужно получать данные о контрагентах.

У всех этих вариантов есть нечто общее:

  • Клиент-серверное взаимодействие, когда вы от себя отправляете данные, а все обрабатывается на стороне сервиса.

  • Сервер не будет хранить ваше состояние – ему без разницы, какой вы запрос отправите, состояние запроса вы должны соблюдать самостоятельно.

  • Используется немного кэширования.

  • Формат ответа – обычно HTML, XML, JSON либо бинарные файлы (если вы что-то получаете в виде картинок или pdf-документов).

 

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

 

 

Какие проблемы возникают в тестировании с API?

  • Основное – стабильность тестов, потому что когда у вас внешнее API – вы целиком и полностью зависите от того, что происходит на сервере. Сервис может уйти на обслуживание, не выдержать нагрузки и, соответственно, ваши тесты тоже перестают проходить.

  • Возможность покрытия сценариев. Тяжело реализовать все сценарии, которые вы можете придумать, когда у вас внешнее API.

  • Большая проблема – скорость ответов. Зависит от того, какая нагрузка на сервере, которым вы пользуетесь, сколько до вас идет ответ.

  • Следующая проблема – риск работы с реальными данными. Если вы тестируете наживую, то можете пересечься с вашими реальными данными, которыми оперирует учетная система. Ничем хорошим это не закончится.

  • Еще есть проблема: можно увлечься, и вместо того, чтобы тестировать, как ваше приложение взаимодействует с API, начать тестировать API. Вы думаете: «А что будет, если я отправлю такой запрос, а если такой, а если здесь пробел поставлю?» И получается, что вместо того, чтобы придумать сценарий, как вы будете взаимодействовать с сервером, вы смотрите, как ответит сервер.

 

Методы решения проблем

 

Какие есть методы решения проблем?

 

 

Самый простой вариант – вам предоставят тестовый стенд. Вам выделяют отдельную область, в которой вы будете тестировать свои алгоритмы.

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

 

 

Следующий вариант – написать свой сервер.

Все программисты, если что-то не работает на стороне, начинают писать свое. Делаем небольшой сервер – берем Python или OneScript.Web – и пишем небольшие заглушки. Мы знаем, какие запросы отправляем, готовим под них ответы.

В чем здесь проблема? Его надо писать. Это будет ваше отдельное приложение, которое надо поддерживать.

 

 

Следующий вариант – использовать специальные mock-сервера (заглушки).

Для них все равно нужно будет готовить данные.

При этом вам нужно не забывать за этими данными следить – вы поставили заглушку, у вас тестирование прекрасно проходит, но если на «боевой» уже поменялся API, и у вас тестируется не реальная ситуация.

Mock-сервер можно использовать только для тестов. Никаких альфа-бета-тестирований на mock-сервере проводить не стоит – для этого нужно использовать только боевой контур.

 

 

Последний вариант – решить все архитектурно, написать приложение так, чтобы оно само в себе содержало тестовые данные и могло их в любой момент использовать. Это самый сложный вариант, мы не будем на нем останавливаться

Мы разберем мокирование.

 

Мокирование

 

Мокирование от английского mock – «заглушка». Выглядит это следующим образом.

 

 

Запускается тест.

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

  • Далее тест обращается к вашей системе, чтобы она отправила запросы не на реальный сервер, а на заглушку.

  • Заглушка присылает ответы, а тест верифицирует: правильные ли данные получила система.

 

 

Вариантов таких мок-серверов много, перечислю самые популярные.

  • Один из первых, который мне попадался – это Postman, в нем есть возможность мокирования. Postman – одно из мастхэв-решений, если вы пишете интеграцию. Работать с запросами в нем очень удобно. И также в нем есть собственная возможность мокирования. Достаточно слабенькая, но есть.

  • SoapUI – достаточно мощное решение, там есть запись ваших запросов, их воспроизведение, упаковка в сценарии. Достаточно популярное решение для мокирования.

  • Еще есть сервис WireMock.

  • Есть сервис МоckServer. С ним я еще не разобрался, он достаточно сложный.

  • И есть JSON-Server – легкое решение, в нем есть база данных, основанная на JSON. Он умеет сохранять данные и преобразовывать.

Но я вам хочу рассказать про работу с WireMock.

 

WireMock – запуск, возможности, управление

 

 

Что такое WireMock?

  • WireMock – приложение на Java, что уже хорошо. Значит, вы сможете его запускать и на Windows, и на Linux.

  • Он умеет работать в режиме JUnit, когда вы пишете тесты на Java, и Standalone – как отдельно запускаемое приложение. С 1С я его чаще использую как Standalone.

  • Он очень хорошо управляется через HTTP-запросы. Когда вы его как Standalone подняли, он управляется, отправляя запросы на нужный адрес.

  • Все настройки он хранит в JSON-формате – это очень удобно, потому что JSON хорошочитаемый, его удобно смотреть при code-review.

  • У него есть функция записи и воспроизведения – чуть позже расскажу, что это такое.

  • Также он умеет назначать приоритеты шаблонам, умеет работать с состояниями и симулировать ошибки.

Чтобы было понятнее – давайте разберем конкретную задачу.

 

Практика

 

 

Наша задача – сделать погодный виджет для Бухгалтерии 3.0. Я достаточно часто встречал такие обработки на Инфостарте – видимо, многие клиенты хотят знать погоду, не выходя из 1С.

Мы выведем на главной странице Бухгалтерии 3.0 текущий прогноз погоды и постараемся максимально закрыть это тестами.

Реализация выглядит вот так – это расширение, которое я нашел на Инфостарте в публикации //infostart.ru/public/801039/. Оно выводит погоду – сейчас +18 градусов.

Давайте накроем его код тестом.

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

Насколько это будет стабильный тест? С утра у нас было +7, днем стало +15, два часа назад пошел дождь, но теперь светит солнце. Соответственно, тест будет совершенно нестабилен – каждый раз, когда меняется погода, тест будет падать.

Как раз его мы и попробуем замокировать.

 

Подготовка

 

Первым делом, нужно провести подготовку.

  • Настроить запуск 1С в режиме тестирования.

  • Научиться перенаправлять запросы – чтобы запросы отправлялись не к внешнему сервису, а к нашему.

  • Подготовить набор ответов.

Начнем с запуска в режиме тестирования. Я обычно реализую такой метод через параметр сеанса, который зависит от параметра запуска.

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

Теперь насчет подготовки мокированных ответов.

У WireMock есть специальноеприложение – WireMockUI, которое позволяет настроить следующую вещь: мы в нем указываем, какой сервис API мы хотим мокировать, на какой сервер мы его перенаправляем.

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

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

Шаблон выглядит вот так: здесь URL запроса и ответ.

Содержание большого JSON-ответа можно упаковать в отдельный файлик – его адрес будет указан в свойства bodyFileName.

Вот так выглядит этот JSON-файл ответа.

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

 

Макеты

 

Давайте подробнее разберемся, что такое макет.

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

Самое первое, что есть в шаблонах – какой HTTP-метод мы используем.

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

Дальше мы разбираем, куда уходит наш запрос.

  • Первый вариант – использовать свойство url, которое описывает полное соответствие, включая все параметры. Мы прямо говорим, что если мы делаем GET-запрос по такому-то URL – возвращай ответ. Это не очень удобно, потому что в коде могут поменяться местами параметры, некоторые параметры будут являться обязательными или необязательными.

  • Поэтому следующий вариант – в свойстве urlPattern написать регулярное выражение, которое будет разбирать вашу строку.

  • И совсем простой вариант – с помощью свойства urlPath указывать только начальный путь. Чаще всего я использую именно этот вариант, когда указываю, что запрос будет по такому-то URL, а потом отдельно обрабатываю параметры запроса через свойство queryParameters.

Есть несколько вариантов обработки параметров:

  • equalTo – это точное соответствие, когда вы говорите, чему должен быть равен этот параметр;

  • matches – регулярное выражение, которому этот параметр должен соответствовать.

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

С помощью свойства bodyPatterns есть возможность обрабатывать тело запроса. В зависимости от того, какой запрос вы обрабатываете, можно использовать:

  • XPath-язык – свойство matchesXPath;

  • JSONPath – свойство matchesJsonPath;

  • или описывать полное совпадение тела запроса через свойства equalToXml и equalToJson.

Это все, что касается шаблона запроса.

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

Вы можете готовить динамические ответы:

  • указывать дату в определенном формате;

  • разбирать входящие параметры, если это требуется;

  • там есть конкатенация строк и т.д.

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

 

Stateful

 

Разберемся, что делать, если у нас есть зависимость от состояния. Сервер не хранит состояния обмена по API, но бэкэнд может какие-то состояния хранить.

Например, если у вас сервис учитывает контроль остатков. Вы делаете запрос остатков, списываете товар, делаете еще один запрос – у вас товар должен закончиться. Получается, у вас есть несколько состояний.

WireMock позволяет это реализовать:

  • у него есть понятие сценария;

  • каждый сценарий должен находиться в определенной стадии;

  • эти стадии можно переключать как прямым запросом по HTTP, так и самим сценарием.

Например, здесь на слайде указан сценарий «To do list», и текущее состояние у него стартовое (“requiredScenarioState”: “Started”).

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

Нам потребуется два шаблона:

  • один стартовый (“requiredScenarioState”: “Started”),

  • другой я назвал bad (“requiredScenarioState”: “bad”) – сейчас объясню, почему.

Логика такая – когда наш сервер стартует, он находится в стартовом состоянии и подает нужный ответ.

А когда мы переключим его в новое состояние, данные на виджете должны измениться.

Как это будет выглядеть в тесте? Мы указываем, что работаем со сценарием Weather.

Прямо в коде явно переключаем его состояние – тогда через 30 секунд у нас меняется погода на виджете.

 

Аварийные ситуации – низкая скорость, обрыв, мусор

 

Плохо, когда пользователю показывают сообщения об ошибке. Они чаще всего пугаются, их закрывают и не сознаются, что у них были ошибки вообще.

Лучше постараться обработать эти аварийные ситуации – повторно отправить запрос или подсказать пользователю.

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

Как это можно реализовать с помощью мокирования?

Первое – задержка ответа. Прямо в шаблоне можно указать, что нам потребуется какая-то задержка.

  • Она бывает фиксированная, когда вы говорите, что каждый запрос должен быть задержан на 1000 миллисекунд, на 3 минуты...

  • Есть вариант показать, что это уже случайная величина на каждый запрос.

  • И есть интересный вариант – цепочка ответов, когда ваш запрос идет с задержкой в 1000 миллисекунд пятью пачками (каждые 200 миллисекунд отправляет пачку ответов) и в конце концов собирается. На слайде показано, как это может быть реализовано.

Еще интересный вариант, что делать, если вам пришел вообще невалидный ответ сервера:

  • вам может прийти пустой запрос;

  • может прийти мусор в ответе – когда вначале был json, а потом абракадабра;

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

На слайде показано, как выглядит запрос Postman, когда приходит совсем пустой ответ – он не может ничего прочитать.

Если вы перехватите такую ошибку, 1С это более-менее переваривает.

 

Интересный вариант реализации – как протестировать обрыв связи. Реализуется как раз цепочками состояний.

  • есть стартовое состояние – Started;

  • дальше мы получаем валидное состояние с погодой – Good;

  • переключаем наш сценарий запросом CONNECTION_RESET_BY_PEER на состояние Conn_reset («Оборвать соединение»);

  • и снова переключаем на хорошее – Good.

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

 

Резюме

 

Как итог всего этого – вы получаете:

  • стабильную проверку позитивных и негативных сценариев, не угрожая продуктовому серверу;

  • вполне параллельно тестируете локально – тестировщики тестируют у себя, одновременно гоняются тесты на сервере, все замечательно;

  • также можете проверять неадекватные ситуации – сбои, менять ответы, если что-то пошло не так, мусор в ответы наваливать.

Все это позволит вам повышать качество ваших продуктов.

 

Полезные ссылки

 

Накину чуть-чуть полезных ссылок, что можно почитать подробнее:

Проекты на GitHub

  • Виджет «Погодка», который я использовал https://github.com/petypen/Pogogka20

  • Мой демо-стенд: https://github.com/KrapivinAndrey/infostart2020-DevOps1c-Mockdemo – можете зайти и посмотреть все сценарии, которые я вам показал. Плюс еще парочка реализованных. Возьмите и попробуйте их локально позапускать, посмотреть, как это все устроено.

 

Вопросы

 

Где взять шаги для фич, чтобы работать с WireMock?

Шаги можно взять там же, у меня в репозитории

Пробовали ли вы использовать OneScript.Web в качестве мок-сервера?

Как я уже сказал, когда пишешь сам, проблема в том, что нужно писать. Первый сценарий мы реализовали на Python, потом переписали на OneScript.Web. Но когда начинается усложнение системы, ты понимаешь, что у тебя есть твой код, теперь тебе еще нужно поддерживать свой мок-сервер. Зачем, если уже люди постарались и написали готовое решение.

Как изменяется состояние сервера? Это какая-то опция в командной строке его запуска?

Во-первых, нужно создать шаблон ответа для этой стадии при этом имени сценария. Само состояние меняется сценарием – там есть шаг, который напрямую направляет запрос к WireMock и меняет стадию. И при выполнении запроса есть опция, что этот запрос переключает на следующую стадию.

Непонятно, в каком формате смотреть результаты тестов.

Результаты тестов смотреть в привычном формате – Allure, Junit. Как обычно, мы проверяем результаты нашего тестирования в фреймворке тестирования – например, Vanessa ADD. Мы не тестируем API, мы тестируем поведение нашей системы – мы отправляем запрос, ожидаем, что поле будет иметь такое значение. Если это не так, очевидно, что тест провален.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "DevOps в 1С: Тестирование и контроль качества решений на 1С". Больше статей можно прочитать здесь.

Приглашаем всех 11-12 ноября принять участие в INFOSTART EVENT 2021 в Москве: //infostart.ru/events/1451228/

Специальные предложения

Оставьте свое сообщение

См. также

Тестер: частые вопросы Промо

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Ошибкам бой - тесты норма жизни!

25.07.2018    32782    grumagargler    31    

Интерактивная справка и помощник первого запуска Vanessa Automation

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Недавно у нас появился помощник первого запуска и интерактивная справка

21.06.2022    1755    fenixnow    0    

С чего начать внедрение автотестов

Тестирование QA Бесплатно (free)

На митапе «Путь к идеальному коду» выступил программист 1С Алексей Степаненко. Алексей рассказал о важности автоматического регрессионного тестирования и предложил инструмент, реализующий методику «Тестирование черного ящика», с внедрения которого легче всего начать внедрение автотестов.

18.05.2022    1982    stepan96    0    

Нагрузочное тестирование 5000+ пользователей онлайн — играем в игру

HighLoad оптимизация Тестирование QA Бесплатно (free)

Тестируем ERP под Postgre SQL. Альтернативный нагрузочный тест.

16.05.2022    5386    ivanov660    50    

Как начать писать тесты без регистрации и СМС

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Данная статья рассчитана на людей, которые только хотят начать тестировать свои собственные наработки, но не до конца понимают, с чего начать. На практических примерах показывается, как можно начать тестировать свой код без использования дополнительного ПО / обработок / режимов запуска и прочего. Теории минимум, все отсылки собраны в заключении.

11.05.2022    1085    zeltyr    3    

Тестирование - игровое моделирование

HighLoad оптимизация Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Мы рассмотрим подход к тестированию с применением элементов искусственного интеллекта

25.04.2022    1147    ivanov660    0    

Практические кейсы и примеры создания сценарных тестов с использованием фреймворка Тестирование 3.0

Тестирование QA Бесплатно (free)

Начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков на Infostart Meetup DevOps продемонстрировал коллегам работу фреймворка «Тестирование 3.0», рассказал о процессе совместной разработки тестов и порассуждал о мировых тенденциях в тестировании.

11.06.2021    8012    ivanov660    26    

Vanessa Automation. Как начать создавать видеоинструкции

Тестирование QA Бесплатно (free)

Автоматические видеоинструкции на основе сценариев тестирования поражают воображение. Но многие сталкиваются с проблемами при попытке создать собственные фичи для видео. В ходе мастер класса на онлайн-митапе «DevOps в 1С» Светлана Попова рассмотрела особенности создания видеоинструкций с помощью Vanessa Automation для SikuliX и веб-клиента. И рассказала, какие подводные камни нужно учесть при их написании.

26.05.2021    6666    SvVik    12    

Ищем паттерны в сценарных тестах. Практика - Фреймворк Тестирование 3.0

Корректировка данных Тестирование QA Бесплатно (free)

Выполняем полуавтоматический поиск паттернов в записанных новых или существующих сценариях и заменяем на готовые скрипты действий из библиотеки сценариев.

29.03.2021    1848    ivanov660    0    

Hello world в Vanessa-ADD bddRunner

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Минимальный пример на Vanessa-ADD bddRunner без теории. При написании использовались: 1С 8.3.10.2753, Vanessa add 6.6.5.

24.02.2021    1377    kirinalex    0    

Практика применения DevOps. Тестирование

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В третьей части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступила Светлана Попова. Она рассмотрела возможности использования двух инструментов тестирования от фирмы «1С» – «Сценарного тестирования» и связки СППР и Vanessa Automation, и рассказала про плюсы и минусы каждого из этих вариантов.

11.12.2020    6692    SvVik    0    

Тестирование серверного поведения с Vanessa Automation

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Обзор модуля "ИнициаторДанных" (версия VA 1.2.034), пример скрипта

14.09.2020    3716    unichkin    18    

Vanessa, видеоинструкции для web-клиента

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Vanessa-Automation. Использование видеоинструкций в web-клиенте.

01.06.2020    4465    SvVik    3    

Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

Рефакторинг и качество кода Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

29.05.2020    6112    grumagargler    14    

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

Тестирование QA Бесплатно (free)

Продолжаю (и заканчиваю) тему с автоматическим решением инцидентов. Перейдем от теории к практике.

25.02.2020    5289    Repich    9    

Использование машинного обучения для решения инцидентов

Тестирование QA Бесплатно (free)

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

18.02.2020    8767    Repich    17    

Тестирование: Отлаживаем и тестируем REST интерфейс 1С с помощью SoapUI

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Рассмотрим быстрый и удобный способ облегчения разработки и отладки REST, SOAP веб сервисов, а также создания автоматизированных тестов.

03.02.2020    8025    ivanov660    4    

Vanessa Automation + СППР

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Vanessa Automation. Использование автоматизированного тестирования в СППР.

07.11.2019    18538    SvVik    15    

Vanessa, улучшаем инструкции

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Vanessa Automation умеет делать хорошие инструкции, давайте посмотрим, какие инструменты для этого есть.

30.10.2019    12451    OPM    12    

Vanessa, хочу все и сразу

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Vanessa Automation это инструмент для тестирования прикладных решений на платформе 1С, но он/она может больше, чем только тестирование.

11.10.2019    17050    OPM    36    

Интерактивная отладка

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Инструменты не панацея - главное подход эффективный.

13.08.2019    4861    kuzyara    7    

Как стать контрибьютором Vanessa Automation?

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Краткая инструкция о том, как помочь проекту VA

15.07.2019    8305    fenixnow    43    

Интеграция сценарного тестирования в процесс разработки

Тестирование QA Бесплатно (free)

Разработчик системы «Тестер» Дмитрий Решитко в своем докладе на конференции INFOSTART EVENT 2018 EDUCATION показывает, что процесс тестирования можно очень плотно интегрировать в процесс разработки, что внедрение тестирования – это возможность развития программиста как такового, позволяющая ему упорядочивать ход мыслей и оставаться «в фокусе». Навыки построения процесса кодирования на стыке с тестированием сокращают время на концентрацию, освобождают от страха перед изменениями и улучшают память разработчика.

08.07.2019    10833    grumagargler    7    

Разработка и сценарное тестирование с Vanessa-ADD. Отчетность Allure. Автоматизация запуска сценариев

Тестирование QA Платформа 1С v8.3 Россия Бесплатно (free)

Формируем отчетность о результатах выполнения сценариев. Автоматизируем запуск.

26.02.2019    32606    Vladimir Litvinenko    28    

Разработка и сценарное тестирование с Vanessa-ADD. Установка инструментов. Запись действий пользователя и выполнение сценариев

Тестирование QA Бесплатно (free)

Вторая часть цикла публикаций, посвященных Vanessa-ADD и автоматизации тестирования.

21.01.2019    56746    Vladimir Litvinenko    98    

Автоматизация тестирования с помощью WinAutomationUI

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Рассматривается использование инструмента WinAutomationUI для создания автоматизированных сценарных тестов на примере 1 + 1 = 2.

11.12.2018    7811    AlexKo    30    

Новичок в TDD

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Краткие итоги первых шагов при разработке в 1С через TDD.

08.10.2018    12458    Alligator84    86    

Автоматизация тестирования

Тестирование QA Бесплатно (free)

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

04.10.2018    13646    ivanov660    23    

Проблемы с запуском TestClient. "Ошибка сетевого взаимодействия при вызове"

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

При выполнении кода автоматического тестирования появляется ошибка "Ошибка сетевого взаимодействия при вызове"

05.07.2018    6260    chugada    3    

BDD в 1С

Математика и алгоритмы Тестирование QA Бесплатно (free)

Я расскажу вам про магию BDD. Сначала будет немного теории, а потом я покажу, как это применимо к 1С на практике. BDD расшифровывается как Behavior Driven Development, разработка через поведение системы. Это означает, что мы выстраиваем весь наш процесс разработки, исходя из ожидаемого поведения.

30.08.2016    30758    Pr-Mex    19    

Опыт практического применения методики BDD на 1С. Написание сценариев

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Эта статья открывает цикл публикаций, в которых я хочу поделиться опытом использования методики BDD при разработке на 1С. В этой статье речь пойдёт о написании сценариев.

03.07.2016    26459    oleynik.dv    131    

Как протестировать неэкспортные процедуры модулей

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Процедура для доступа к внутренним методам модуля без нарушения инкапсуляции.

17.11.2015    14457    json    30    

xUnitFor1C - набор инструментов для выполнения тестирования (модульного/юнит, приемочного, сценарного для 1С 8.3, интеграционного) в 1С:Предприятии 8

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

xUnitFor1C - простой и мощный фреймворк для тестирования в 1С. Позволяет тестировать в разных режимах обычное приложение, тонкий и толстый клиент управляемого приложения. Поддерживаются любые платформы 1С - от 8.2.17 до 8.3.5 и выше. Любые наборы тестов могут прогоняться в полностью автоматическом режиме. Автозапуск используется в различных build-серверах в системах Continuous Integration. Также возможно очень простое создание тестовых данных на основании табличных макетов. Эти макеты можно генерировать из реальных боевых данных. Полученные данные в тестах загружаются одной строкой кода. В статье я кратко описал историю продукта + вставил небольшое описание различных возможностей нашего фреймворка + список полезных статей/примеров/видео, обучающих/рассказывающих о практическом применении инструмента

13.11.2015    49495    artbear    53    

Механизмы тестирования в 1С. Использование методики TDD (разработка через тестирование) в 1С

Тестирование QA Бесплатно (free)

Данная статья написана по материалам доклада, прочитанного автором на первой конференции инфостарта 2012 года. Она опубликована в журнале Инфостарта №1.

09.02.2015    89351    artbear    54    

Автоматизированное тестирование в 8.3

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной статье будет рассмотрен новый механизм системы "1С:Предприятие 8" поддерживаемый начиная с платформы версии 8.3. Механизм позволяет легко и быстро создавать различные сценарии тестирования, без необходимости написания сложных процедур и функций для имитации действий пользователя.

06.03.2014    71354    M.Shalimov    47    

Простая отладка внешних обработок

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Простой способ, упрощающий отладку внешних обработок, печатных форм и тд. ВНИМАНИЕ! Данный метод НЕ работает в режиме работы "Управляемое приложение"! Статья актуальна только для режима "Обычное приложение"

22.10.2013    69236    EvilDoc    69    

Неблагодарное это дело – выдавать сообщения об ошибках

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Методика формирования и выдачи сообщений об ошибках. Описывается способ работы над ошибками в данных, прилагается программный код. Приводятся примеры.

28.09.2013    6277    pakill    16