Вы сможете убедиться, что создание тестов на самом деле это относительно быстрый и простой процесс.
Окружение для теста – конфигурация: ЕРП 2 (демо база версия 2.2.4.59, 2.2.3.231, 2.1.3.195)/УТ 11 (демо база 11.3.3.205); Фреймворк xUnitFor1C, внешние обработки (см. приложения) .
Задача теста — проверить корректность работы функции «СкладыСервер.ПереоформитьРасходныеОрдера»; с пользовательской стороны — это проверка кнопки «оформить расходные ордера по заказам» рабочего места «управление отгрузкой» (см. рис. ниже).
Условие проверки — при «имитации» нажатия кнопки «оформить ордера» должен будет сформироваться документ «Расходный ордер на товары» и табличная часть этого документа должна будет соответствовать некоторой эталонной таблице значений.
Шаг 1. Определяемся с данными для теста.
1.1 НСИ: склад будет ордерный и существующий в демо базе «Магазин «Продукты»», организация «Торговый дом «Комплексный»», контрагента создадим нового «ООО Ромашка», также создадим новое типовое соглашение и договор контрагента (можно подобрать существующие).
1.2 Документы: нам нужно будет создать только два документа «Заказ клиента» (отгружать его будем в кредит) и «Расходный ордер на товары».
1.3 Дополнительно: можно создать документы поступления, это поможет решить проблему отсутствия/нехватки товара – «Поступление товаров и услуг» и «Приходный ордер на товары» (не обязательно).
Шаг 2. Создаем «эталонную» цепочку. В большинстве случаев рекомендуем создавать документы, а НСИ использовать существующую.
2.1 Создаем контрагента, партнера, типовое соглашение и договор контрагента.
2.2 Оформляем заказ, ставим его в отгрузку.
2.3 Создаем расходный ордер и снимаем его с проведения. Это будет наш эталонный документ для сравнения.
Шаг 3. Создаем макет данных, с помощью плагина «СериализаторMXL».
вариант «а» — быстрый
3.1 Открываем обработку в предприятии и остаемся на вкладке «Метаданные».
3.2 Устанавливаем в свойствах генерации макета флажки: «Выгружать ссылку», «Связь по ГУИД», «Обмен Данными», «выгружать с документом его движения», «Уровень выгрузки зависимых» в значение «2».
3.3 Указываем документ «Заказ клиента» и «Расходный ордер на товары» в дереве метаданных или жмем кнопку «Структура подчиненности».
В форме указываем тип данных «Заказ клиента» и находим наш документ, далее добавляем в корзину и передаем в основную форму (см. рис. ниже).
Для удобства работы можно скрыть не выбранные элементы дерева метаданных с помощью кнопки «Только выбранные» .
3.4 Создаем и сохраняем макет (в обработке плагине «СериализаторMXL» кнопки «Создать макет данных» и «Сохранить макет в файл»).
3.5 Поверяем макет на другой «копии базы», т.е. убеждаемся, что мы выбрали все необходимые данные и не будет ошибки при подгрузке данных.(в обработке плагине «СериализаторMXL» для этого есть кнопки команды «Загрузить макет из файла» и «Протестировать загрузку макета»)
вариант «б» — только то что нужно
3.1 Открываем обработку в предприятии и остаемся на вкладке «Метаданные».
3.2 Устанавливаем в свойствах генерации макета флажки: «Выгружать ссылку», «Связь по ГУИД», «Обмен Данными». Также в дереве подчинённости снимем флажки «Выгружать при необходимости».
3.3 Жмем кнопку «Структура подчиненности» (особенности работы были описаны выше).
3.4 С помощью кнопки «Проставить отбор подчинённых ссылок» из текущей строки документа в быстром режиме подбираем справочники, которые хотели выгрузить – это контрагент, договор контрагента и еще рекомендуем добавить справочники вида «ключи аналитик» (принцип работы аналогичен кнопке структура подчиненности).
3.5 Выбираем все движения регистров через кнопку «установить отборы для регистров» для документа «Заказ клиента» (для этого позиционируем необходимую строку документа и жмем кнопку отборов для регистров).
3.6 Сохраним настройки дерева в файл. Это позволит довольно быстро восстановить настройки макета для повторного сохранения.
3.7 Создаем и сохраняем макет.
3.8 Проверяем макет на другой «копии базы», т.е. убеждаемся, что мы выбрали все необходимые данные, в противном случае добавляем недостающую информацию в выгрузку.
Шаг 4. Подготовка обработки для создания юнит теста.
4.1 Берем шаблон обработки для серверного теста.
4.2 Открываем в конфигураторе и переименовываем шаблонные функции на созвучное нам имя теста (в модуле обработки и в модуле управляемой формы) как «ПроверитьФункциюОформленияРасходныхОрдеров».
4.3 Вставляем в обработку наш макет с начальными данными и называем его как «МакетДанных» (выгрузка см. шаг 3).
4.4 Сохраняемся.
Шаг 5. Создаем код теста. Ниже приведены логические пункты, на которые мы советуем разбить исходный код теста.
5.1 Подготавливаем данные для выполнения проверки функции.
5.2 Формируем параметры для функции.
5.3 Выполняем функцию.
5.4 Обрабатываем результат. Если документы создались, то выполняем сравнение табличных частей эталонных документов (из макета) и документов, созданных при выполнении процедуры. Сравнивать рекомендуем, только значимые колонки (нет смысла сравнивать внутренние ключи и т.п.).
Код функции проверки:
////////////////////////////////////////////////////////////////
// I получение данных из макета
// 1.1 из макета
МакетДанные = ПолучитьМакет("МакетДанные");
СозданныеДанные = СериализаторMXL.СоздатьДанныеПоТабличномуДокументу(МакетДанные);
Склад = СозданныеДанные.ЗаказКлиента.Склад;
Получатель = СозданныеДанные.РОМАШКАООО_Партнер;
ЗаказКлиента = СозданныеДанные.ЗаказКлиента;
РасходныйОрдерНаТовары_Эталон = СозданныеДанные.РасходныйОрдерНаТовары;
РасходныйОрдерНаТовары_Битый = СозданныеДанные.РасходныйОрдерНаТовары_Битый;
// 1.2 готовим входные параметры для функции
СтруктураПараметровСозданияРасходныхОрдеров = СкладыСервер.ПараметрыПереоформленияРасходныхОрдеров();
СтруктураПараметровСозданияРасходныхОрдеров.Склад = Склад;
СтруктураПараметровСозданияРасходныхОрдеров.РаспоряженияНаОтгрузку = новый Массив;
СтруктураПараметровСозданияРасходныхОрдеров.РаспоряженияНаОтгрузку.Добавить(ЗаказКлиента);
СтруктураПараметровСозданияРасходныхОрдеров.Получатель = Получатель;
////////////////////////////////////////////////////////////////
// II вызов проверяемой функции
СтруктураОтвета = СкладыСервер.ПереоформитьРасходныеОрдера(СтруктураПараметровСозданияРасходныхОрдеров);
////////////////////////////////////////////////////////////////
// III обработка и проверка результата
// 3.1 Внутренняя ошибка
БазовыеУтверждения.ПроверитьЛожь(СтруктураОтвета.ЕстьОшибка,"Внутренняя ошибка при создании расходных ордеров");
БазовыеУтверждения.ПроверитьНеРавенство(СтруктураОтвета.ОформленныеОрдера.Количество(),0,"Внутренняя ошибка. Не удалось создать ордера");
// 3.2 Сравним с эталоном
// выгружаем только проверяемые колонки, некоторые необходимо проигнорировать
СтрокаНужныхКолонок="Номенклатура,Характеристика,Назначение,Серия,Упаковка,
|КоличествоУпаковок,Количество";
УтвержденияПроверкаТаблиц.ПроверитьРавенствоТаблиц(РасходныйОрдерНаТовары_Эталон.ОтгружаемыеТовары.Выгрузить(,СтрокаНужныхКолонок),
СтруктураОтвета.ОформленныеОрдера[0].РасходныйОрдер.ОтгружаемыеТовары.Выгрузить(,СтрокаНужныхКолонок));
Шаг 6. Проводим отладку теста. Сразу может заработать только простейший пример из разряда «2+3=5» (без этой функциональности первоначально юнит тесты у нас не поехали).
6.1 Отключаем у пользователя защиту от опасных действий, в противном случае будут проблемы с загрузкой плагинов и менеджера юнит тестов.
6.2 Открываем обработку в предприятии на тестовой базе.
6.3 Указываем требуемые серверные пути (у нас на сервере разработки расшаренный каталог GIT, где находится все что необходимо).
6.4 Ставим точки останова и отлаживаем.
Шаг 7. Завершение. Все готово! Помещаем тест в рабочую папку/хранилище GIT, настраиваем задания для выполнения тестов.
Бонусы!
А) Мы добавили обработку пример. В обработке примера две функции — правильная и битая (приводящая к ошибке для демонстрации). Кроме правильного эталонного расходного ордера есть еще «битый», при котором сработает наша проверка на равенство таблиц. В результате его выполнения мы увидим текст сообщения об ошибке – не совпадают табличные части в таких-то позициях (см. рис. ниже).
Б) В приложениях есть шаблон обработки с встроенным блоком для отладки и двумя примерами заготовками (загрузка данных из макета и выполнение простой функции).
Советы:
1. Запускать тесты удобно через Jenkins, TeamCity, а еще можно через Windows Task Manager.
2. Смотреть тесты красиво позволяет свободный фреймворк Allure.
3. Для удобства создания данных для тестов мы внесли некоторые изменения в плагин «СериализаторMXL», что оптимизировало процесс работы с ним: добавили возможность сохранения дерева настроек, загрузку макета, отбор документов по структуре подчиненности и пакетное формирование движений для выбранных документов, кое-что поправили еще; (в рамках нашего процесса). Есть в приложении, но также можно использовать стандартный плагин фреймворка.
4. Работайте с GIT — это позволит использовать тесты и инструменты работы с ними в командной разработке.
5. Рекомендуем прогонять тесты не только при сборке релиза, но и на ночном билде, а также на базах разработчиков.
6. Актуальную версию, весь необходимый набор плагинов и многое другое Вы можете скачать со странички проекта xUnitFor1C на github.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Плюс за использование нашего фреймворка xUnitFor1C.
Пожалуйста, поделитесь доработанной версией «СериализаторMXL», он общедоступный для всех.
я добавлю его в проект xUnitFor1C на github
(2) К статье прикрепить бесплатно система не дает, скидываю в комментах
(1) Других «достойных» фреймворков для юнит-тестов мы не нашли 🙂
(3) Спасибо.
Есть более расширенное описание изменений плагина, чем в статье?
Если да, поделись. Можно в личку.
(0) Добавил статью в список статей в
(5) отправил в личку
(4) Спасибо за статью по теме тестирования! Почему «достойных» у вас в кавычках? 🙂
Вы пробовали сценарное тестирование или тестер? Подобные примеры на мой взгляд не менее элегантно решаются и там. Интересно ваше мнение, почему другие системы не вошли в список достойных.
(8)
Вы пробовали сценарное тестирование или тестер? Подобные примеры на мой взгляд не менее элегантно решаются и там. Интересно ваше мнение, почему другие системы не вошли в список достойных.
Я присоединюсь к высказыванию выше.
Если я хочу использовать TDD для тестирование кода на сервере, то сценарное тестирование подходит плохо. Очень много времени тратиться на прогон теста + в вашей конфигурации метод «Создать» необходимо делать.
А в xUnit можно набросать тест на проведение документа мин за 10.
Минус xUnit, что поведение форм тестировать неудобно. Хочется без открытия самой формы, чтобы все процедуры ПриОткрытии, ПриСозданииНаСервере отработали и там уже проверять свои.
Это сделать можно, но тогда методы форм нужно писать как процедуры с передачей в них Формы или добавлять какие-то специальные методы для тестирования, что неочень хорошо при работе в типовых конфигурациях.
Клиентские методы общих модулей тестировать одно удовольствие
(8) 1. Речь идет про юнит-тесты, а не про сценарные тесты — это «немного» разные вещи.
2. Конфигурация «Сценарное-тестирование» и «Тестер»не подошли нам (Мы решили написать свой «велосипед» для создания сценарных тестов для платформы 1С, про него мы расскажем позже).
(10)
Возможно, тогда ваш пример в статье выбран неудачно. Вы описываете вполне четкий сценарий, только его проверку делаете кодом на сервере, а не кодом сценария. То есть разница тут только техническая, код в обработке на сервере или на клиенте в сценарии, не делает из первого Unit тестирование или TDD, а второе не означает сразу BDD. Поэтому в теории — да, это разные подходы, но в вашем примере — это не так.
Позвольте мне обрушить на вас еще немного критики: ваш пример не удовлетворяет строгости unit-теста, и некоторым его базовым принципам. Также, в нем мало общего с TDD (впрочем, вы это и не декларировали). Заготовка данных идет вручную, она не описана кодом и в шаблоне уже будет потеряна. Нужны две базы, нужны НСИ которые фактически, только в «уме», что произойдет, если поменяются условия теста или изменится структура метаданных, и помножить это на две три сотни тестов — я не вижу как практически можно будет эффективно следить за всем этим хозяйством.
как сделали в свое время и мы, будет интересно посмотреть на ваш подход!
(9)
Поведение форм тестируйте с помощью платформенного «Автоматизированного тестирования». В xUnitFor1C для этого есть плагин
Пример использования:
Показать
(12)
Я так понимаю, речь о типовой конфигурации «Сценарное тестирование»? Она умеет работать в составе какой-либо CI-системы сборки? Gitlab, Jenkins, TeamCity вот это вот всё? Поддерживает ли она запуск из командной строки?
xUnitFor1C всё это умеет, есличо.
(10)
Как раз таки в примере и не видно юнит-теста. Согласен с коллегой выше, что здесь пример сценарного теста.
(15) 1. В статье идет речь о юнит-тесте и проверке функции «СкладыСервер.ПереоформитьРасходныеОрдера».
2. Все что описано в шагах 1,2 — это подготовка и создание данных для проведения юнит-теста.
(Мы внесли эти шаги для того чтобы желающие могли повторить последовательность действий от начала до завершения теста)
3. Конечно же можно написать сценарный тест для проверки задачи переоформления складских ордеров.
возможно ввела в заблуждение фраза «при имитации нажатия кнопки «оформить ордера» должен будет сформироваться документ «Расходный ордер на товары»». Под имитацией я подразумеваю вызвать функцию «СкладыСервер.ПереоформитьРасходныеОрдера».
(12)
На мой взгляд мы с вами дискутируем о том, что покрывать тестами. Вы покрываете тестами конечный функционал. Я пытаюсь покрывать тестами не конечный функционал, а более мелкие блоки.
В идеале нужно совмещать оба подхода.
Может в скором времени и к вашему подходу приду =)
(13)
Спасибо за пример!
Добрый день.
Пользовался при разработки xUnitFor1C. Понравилось.
Однако есть вопросы, может Вы сможете подсказать.
1. Допустим делаю документ, выгрузил в шаблон макет а потом изменились его реквизиты(метаданные) выходит мне надо заново делать шаблон или пытаться править макет вручную. Это не удобно. Есть ли способ лучше?
2. Допустим я тестирую некий функционал который пишет свои результаты в базу, далее мне надо тестить функционал который зависим от предыдущего и тд, те один зависит от другого. Сейчас я просто вызываю из одного теста другой. Насколько это правильно? Если я буду делать шаблоны и не вызывая «предыдущий функционал» сразу вносить данные в базу для работы текущего тестирования то при изменениях мне придется много менять а это очень неудобно.
3. Есть ли какой то способ/рекомендация как организовывать тесты ведь если их много и они тестят функции зависимые от др и при этом прогружают данные из макета(СериализаторMXL) то по прошествии времени не особо помнишь что для чего.
(12) В очередной раз многовато текста, попробую ответить.
Большое лукавство говорить о TDD, юнит-тестах и отдельно о сценарном тестировании, которое используется в различных продуктах.
Сценарное тестирование по своей сути набор последовательных действий, которые идут в сторону одной цели.
Такое тестирование есть в xUnitFor1C, не нужно об этом забывать.
Так называмое «сценарное тестирование» это не только кнопконажималка 🙂
вообще считается, что тесты, завязанные на интерфейс (что как раз и реализовано в автотестировании 8.3), являются самой хрупкой частью по сравнению с остальными видами тестов
А еще есть т.н. сценарное тестирование в нашем же продукте vanessa-behavior — человеческий язык сценариев, отличное переиспользование шагов, большая библиотека шагов, автогенерация инструкций, поддержка автотестирования 1С 8.3 (кнопконажималка и прочее) и многое другое.
и xUnitFor1C и vanessa-behavior отлично и очень давно работают с различными билд-серверами — Jenkins, TeamCity, MS TFS/MS Team Services, Bamboo и т.п.
Получают красивую отчетность по тестированию, в т.ч. и учет трендов по тестам.
Да, подготовка и поддержание инфраструктуры самое сложное.
У нас (Серебряной Пули) 2 базовые рекомендации по подготовке тестовой базы, которые мы предлагаем на обучении различных команд — пустая база или минимальная эталонная база (условно-константные данные (константы, справочники, ПВХ, регистры сведений и т.п.)
но для этого у нас есть различные помощники.
Например, наш генератор данных/сериализатор из xUnitFor1C как раз и разработан с целью минимизации последствий по обновлению структуры метаданных, в отличие от других средств сериализации — конвертация данных или универсальный обмен xml и т.п.
подробнее об этом я напишу в ответе на (18), .вопрос 1.
При использовании так называемого «сценарного тестирования», которое заключается в интерактивном создании необходимых данных через «кнопконажималку» автотестирования 1С 8.3, также возможны проблемы при обновлении. например, исчезновение полей в формах, перенос полей в разные закладки и т.п. и т.д.
Из опыта — проблем в кнопконажималке совсем не мало, падает в самых различных местах 🙁
(18) Спасибо за хорошую оценку нашего открытого и бесплатного продукта xUnitFor1C.
Отвечаю по пунктам:
1. Изменение метаданных — сложный этап.
Но при создании генератора данных в xUnitFor1C мы как раз постарались помочь решить эту проблему.
После изменения метаданных есть несколько способов реагирования.
1.1 ничего не делать 🙂 , т.к. вполне может быть, что добавлен не столь значащий реквизит документ и документ, созданный из макета, все равно будет находиться в консистентом состоянии
1.2 если все-таки добавлен значащий реквизит, можно выбрать один из 2х способов ниже.
1.3 заново сделать шаблон документа. это может быть трудно — например. нет подходящего документа, или на документ много завязано других ссылок
1.4 подредактировать макет вручную !
на самом деле это не так сложно.
+ Структура макета довольно простая и специально сделана для повышения человекочитаемости и человеко-редактируемости. Табличный документ рулит 🙂
+ Генератор специально не загружает/не выгружает, а пропускает поля, значения которых не отличается от полей пустого документа.
+ например, значение Ложь для реквизита с типом Булево не будет выгружено или пустая ссылка для ссылочного типа не будет выгружена.
+ в итоге в макете остаются только значащие поля, в отличие от, например, универсальной выгрузки xml, которая очень зависима от изменения метаданных
+ можно просто добавить несколько полей в макет документа — добавить имя поля, его значение. в большинстве случае этого хватает.
(18) По вопросу № 2
Здесь нет простого решения, все зависит от конкретных особенностей.
Базовые рекомендации
+ либо используйте сценарии, т.е. из одного теста вызывайте другой
+ это возможно разными средствами xUnitFor1C —
+ например, ручной вызов теста из другого теста
+ либо используйте сценарный тест в самом xUnitFor1C — смотрите wiki продукта
+ либо можно развязать эти тесты от взаимного использовании и использовать только данные
+ сгенерируйте макет от первого теста и используйте его во втором.
+ тесты будут независимы, их будет легко проверять и разбирать в случае падения одного из тестов.
Напоминаю, что если тест/сценарий падает, то это возможно по 3-м причинам:
+ изменилось поведение системы (например, программист поменял код)
+ изменился тест
+ изменились данные
и бывает далеко не просто понять, в чем же проблема падения теста, и нужно принимать все меры к упрощению подобного анализа.
1. Актуализировать данные в случае изменений влияющий на проведение теста придется делать — это накладные расходы.
К примеру, можно снизить затраты на обновление, если использовать при загрузке макетов «обмен данными» = истина, тогда новые реквизиты просто будут проигнорированы. В рамках примера, когда мы пробовали тестировать его на некоторых версиях конфигурации ЕРП, то для совместимости мы удалили несколько реквизитов документа «заказ клиента» из макета, которые не влияют на решение задачи.
2. Все зависит от методологического подхода к решению задачи тестирования: делать много тестов, использовать один источник данных для всех тестов, использовать демо базу, использовать лицо, которое следит за актуализацией и др. Это большая и серьезная тема.
3. Удобнее всего использовать какую-либо систему учета тестов с описаниями и возможно ссылками на систему баг-трекинга.
Думаю, что чуть позже мы расскажем про наше видение данной ситуации. И в рамках этого вопроса/тематики я планирую выступить на конференции инфостарта.
Кстати, я уже несколько лет перестал употреблять юнит-тесты в применении к тестированию в 1С, а использую просто тесты или сценарные или приемочные тесты.
В 1С мало юнит-тестов, т.к. тесты чаще всего завязаны на БД.
поэтому лукавство говорить, что в xUnitFor1C, дескать,.юнит-тесты, а вот у нас сценарные тесты, как говорят некоторые коллеги 🙂
и xUnitFor1C и vanessa-behavior отлично и очень давно работают с различными билд-серверами — Jenkins, TeamCity, MS TFS/MS Team Services, Bamboo и т.п.
Получают красивую отчетность по тестированию, в т.ч. и учет трендов по тестам.
Кстати, я очень рекомендую посмотреть на vanessa-behavior.
человеческий язык сильно упрощает жизнь.
30 секунд рекламы 🙂
старт потока 11 сентября!
научитесь продуктивно и качественно работать в 1С.
(18) По вопросу 3
> Есть ли какой то способ/рекомендация как организовывать тесты ведь если их много и они тестят функции зависимые от др и при этом прогружают данные из макета(СериализаторMXL) то по прошествии времени не особо помнишь что для чего.
Есть разные варианты, как всегда 🙂
+ Можно делить по блокам функционала — один каталог на верхнем уровне соответствует одному блоку
+ Можно делить по метаданным — один каталог на верхнем уровне соответствует одному метаданному
+ можно совмещать эти подходы
+ например, создание НСИ — отдельный каталог
+ создание документов — другой каталог
+ блоки функциональности — третий каталог
(14)
— нет, речь технологии тестирования
xUnitFor1C всё это умеет, есличо.
это всё здорово, вопрос лишь в том — насколько это ценно без возможности быстро создавать и управлять тестами как таковыми.
(27)
Да, извини, я и сам не удержался 🙁
Я хотел отвечать небольшими кусками текста, но не справился с этой задачей 🙂
Зачем нам лукавить, все, кто с нами работает, знает нашу открытость, доступность и желание делиться знаниями.
Например, мы указанные вопросы активно исследуем и решаем в рамках наших платных имплементаций инженерных практик для различных команд, а очень часто и вообще бесплатно раздаем 🙂
Ванесса и т.н. «заготовка макета» это все-таки разные вещи, не нужно их смешивать.
БДД — это методика.
А т.н. «заготовка макета» — это один из инструментов, который можно использовать.
Разные инструменты подходят для разных задач. Можно использовать подготовка макетов данных, можно использовать программное создание данных, можно использовать интерфейсное создание данных.
Использовать макеты — это одна из рекомендаций, необязательно ей следовать.
Коллеги, которые проходили у нас обучение, юзают разные способы.
Например, кто-то юзает универсальный обмен данными XML, кто-то юзает даже конвертацию данных, многие кнопкнонажималкой создают, а также пользуются подготовкой через макеты.
Скажи, чем подготовка макетов данных отличается от программного или интерфейсного создания данных в разрезе тобой же указанных разнообразия данных?
ИМХО разница не слишком большая, у всех есть и плюсы и минусы, которые играют роль в конкретных сценариях.
По своему опыту скажу — когда слишком большое разнообразие данных, становится очень не очень удобно или вообще неудобно собирать данные из кирпичиков, чаще проще проще представить единый набор данных для нескольких сценариев.
Условия и циклы в тестах и тестовых сценариях вредны.
в тестах должно быть отражение реальной системы 🙂
1 Если есть некое условие, значит, это не один тестовый сценарий, а несколько.
А раз несколько сценариев у системы, значит, и тестовых сценариев должно быть несколько.
Значит, нужно в тестовой системе нужно зафиксировать эти разные тестовые сценарии
2 если внутри тест.сценария есть условие/цикл, как определить, какой из вариантов условия/цикла выполнялся, а какой нет?
ведь если какой-то не выполнился, значит, проверки этого поведения не было сделано и тестирование задачу проверки поведения системы выполнило только частично 🙁
(29)
Я здесь вижу несколько существенных плюсов.
1. Понимание данных.
— Программно: есть понимание какие данные важны и какова их глубина. Например, если мне для тестирования нужен клиент, и я в тесте его создаю, то я вижу, как я его создаю, я вижу, что передаю только имя контрагента. А валюта, договор, идентификационный код и другое — не передаются, а значит, для теста не важны.
— В макете: плоская таблица с выгруженными данными, является ли этот набор минимальным для создания объекта или это всё нужно для теста — не очевидно.
2. Низкая связность.
— Программно: создавая данные через сценарий, я задаю только то, что требуется, всю остальную работу по формированию сопуствующих данных выполняют обработчики _клиентских_ и серверных событий создаваемого объекта. Мне чтобы создать товар, нужно просто передать наименование, единицу измерения, полное наименование, какие-то записи в регистры уже сделает приложение. Вывод тут такой: при изменении структуры метаданных, мне не нужно думать о том, что я не использую, мне всё равно как там хранится тип товара, признак услуги это перечисление или галка и его вообще удалили.
— Макет: просто выгруженные данные, плоские, при несоответствии какого-то реквизита по типу или наличию как таковому — проблемы.
3. Лучшее покрытие.
— Программно: создавая объект он создается также, как его бы создавал пользователь, что ценно для тестирования
— Макет: загружается в особом режиме, с каким-нибудь ОбменДанными.Загрузка = истина, или не дай бог в транзакции
4. Понимание теста в целом.
— Программно: кроме того, что я вижу какие данные создаются, я вижу еще и как это происходит. Очередность, что за чем. Это дает возможность другим программистам понять мой сценарий и воспроизвести его у себя, в своих условиях
— Макет: не так очевидно, если что-то пошло не так, непонятно, это потому что какой-то реквизит конфликтует или действительно в моем функционале имеет место ошибка
(29)
БДД — это методика.
А т.н. «заготовка макета» — это один из инструментов, который можно использовать.
Разные инструменты подходят для разных задач. Можно использовать подготовка макетов данных, можно использовать программное создание данных, можно использовать интерфейсное создание данных.
Использовать макеты — это одна из рекомендаций, необязательно ей следовать.
Стараюсь не смешивать. Стратегически, у всех предлагаемых способов подготовки данных (из тех, что мне были доступны для прочтения) я вижу один фундаментальный изъян — статичность. Данные живут отдельно от приложения и не эволюционируют с ним. А уже как их там загружать, через макет, конвертацию данных или еще как — неважно. Ну например, используете вы конвертацию и выгружаете каждый раз данные из якобы живой базы. Но сами данные там устаревают, ведь их никто не «передергивает» в связи с изменениями функционала, реквизиты которые стали обязательными для заполнения, какие-то другие связанные данные. Я уже молчу о том, что правила конвертации менять тоже времени стоит, а если идет разработка нового функционала, где у программиста часть реквизитов есть, как версионировать правила? Это же очень тяжело организовать коллективную работу при таком подходе, возможно, да, но эффективность…
А в тестере, вы просто в коде сценария пишите если МояВерсия () тогда….и вся бригада прогеров спокойно работает с одним сценарием создания объекта
(30)
А раз несколько сценариев у системы, значит, и тестовых сценариев должно быть несколько.
Значит, нужно в тестовой системе нужно зафиксировать эти разные тестовые сценарии
Совершенно верно, и я дополню: условий не должно быть в проверяемом сценарии, но это не значит, что условий не должно быть и в инструменте их создания. Например, начальные данные — это тоже условия прохождения теста, и разница лишь в том, что ты их создаешь руками, а не кодом, вот и всё.
(33) заполнение начальных данных — это часть сценария поведения системы, даже для ERP … а вы его сознательно пропускаете
(34) Я к сожалению не понял эту реплику, особенно по части ERP. Разверните мысль.
Вопросы по удобствам. В разделах модуля 1.1 и 3.*, как я понял, контекстной подсказки через точку никак не получится сделать или все таки можно что то придумать?
(36) Если я правильно понял суть вопроса, то сомневаюсь что в общем случае получится дописать как-то плагин(ы), чтобы минимизировать код.
(36) Сергей, разверни свой вопрос, я его практически не понял 🙁
1 — Данные для теста
3 — макет данных, верно?
(38) В публикации есть «Код функции проверки» и в нем есть разделы модуля. Я спрашивал про удобство набора такого кода. Например будет ли подсказка после точки для «БазовыеУтверждения»?
(39) Нет, подсказки не будет, т.к. это внешний модуль — модуль внешней обработки 🙁
Не вижу в этом особой проблемы, т.к. при определенном количестве набора подобных методов они вводятся довольно просто.
Например, для «старых» утверждений пишем Проверить и добавляем нужную проверку — ПроверитьРавенство, ПроверитьТип и т.п.
Некоторые пользуются шаблонами с автоподстановкой, я редко такими шаблонами пользуюсь
для «новых красивых/текучих» утверждений также все просто
шаблон Ожидаем.Что(Значение, ТекстОшибки).Это().Равно(2) или .ЭтоНе().Равно(1) и т.п.
тут можно пользоваться одним шаблоном.
Я правильно понял что надпись «Фреймворк xUnitFor1C» подразумевает что во внешних обработках скрыт бинарный код?
(41) Нет, не правильно. Весь фреймворк — набор обработок, не более чем. Все открыто, лежит а гитхабе. можешь вполне спокойно скачать и изучить
(42) Спасибо, тогда всё намного интереснее. Поставил звёздочку публикации 🙂
Если для тестов нужны какие-то общие данные, то для этого я, например, делал отдельную обработку-тест.
А чтобы проверять движения документов, и что другие движения не мешались (актуально для тестов закрытия месяца) я написал плагин РаботаСДокументами, где есть функция УдалитьДокументы(Организация)
(44) Как эта обработка поступает, когда документ нельзя удалить, т.е. на него есть ссылки?
(45) там удаляются все документы и рс. список метаданных задается вручную