Добавление конфигурационных параметров для настройки тестов

[artbear]

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

Например, для тестов открытия форм конфигурации нужно задавать исключения форм, которые не требуется тестировать #179
Для тестов пользователей с ограниченными правами нужно задавать список пользователей и/или наборы прав, с которыми нужно запускать эти тесты.

Предлагаю следующее:

• при тестировании возможно указать настроечный xml-файл, в котором будут храниться индивидуальные настройки для тестов
  • при интерактивном тестировании файл можно выбрать вручную
  • при запуске из командной строки будет добавлен спец.параметр config-file, указывающий на путь к файлу настройки
  • формат хмл-файла - это простое дерево, где узлом является имя/идентификатор тестового набора, а листьями являются конкретные параметры для тестирования
• в ядро xUnitFor1С (для сервера и УФ-клиента) будет добавлен набор методов для получения параметров настройки

Обсудим?

[pumbaEO]

Ты в юнит тесты пытаешься засунунть интеграционные тесты.

Простая генерилка текста bdd позволяет тебе тебе уже получить разлчиные настройки для сценариев. В частности у меня так выглядит тестирование открытия форм для различных подсистем.

и код тестовой обработки вот так выглядит

[artbear]

@pumbaEO Женя, я уже давно не говорю "юнит-тесты", а в нашем проекте, да и в разработке для 1С работаю над различными видами тестов.
Сам знаешь, в рамках 1С очень сложно сделать "чистые" юнит-тесты :)

И настройка тестов под конкретную конфигурацию ИМХО не является злом :)

подход с БДД очень интересен, и мы к нему движемся.
Картинки у тебя интересные.

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

В БДД есть очень полезные фишки, например, повторное использование шагов мне очень нравится. Но пока не все проблемы использования решены :(

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

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

[pumbaEO]

1. Работает в linux и windows.
2. Тест обратно совместим с юнит тестами, т.е. когда идет генерация сценария то формирую только процедуру "ПолучитьСписокТестов" и туда в массив добавляю все шаги (хоть они и могут повторятся).
3. Повторно используемый код, т.е. приоритет поиска процедуры для выполнения ищу по текущей фиче, если не нахожу, то ищу по всему дереву тестов. Позволяет мне вынести библиотечные функции и тесты в отдельные обработки и использовать их повторно.

[artbear]

Это плюсы.
А замеченные недостатки есть?

[pumbaEO]

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

[artbear]

@pumbaEO по БДД понятно.

А что еще ты можешь сказать по конфигурационной настройке?
Нужно вообще?
если нет, как реализовать указанную доп.настройку тестов (без БДД) ?
если да, что скажешь по формату настройки? может быть, предложишь другие варианты?

Кто еще что может добавить?
@allustin ? @kuntashov ? @wizi4d ? @ValeraS ?

[ValeraS]

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

[artbear]

Согласен про функциональность теста, но в режиме УФ на сервере у формы нет доступа к файлу на клиенте, т.е. тест тупо свои настройки прочитать не сможет :(

Правда, это можно сделать в ПолучитьСписокТестов при его вызове с клиента.
Но чисто серверный тест, который определен только в модуле обработки, даже при чтении внутри ПолучитьСписокТестов файл с клиента не получит, т.к. этот метод будет вызван только на сервере :(

[wizi4d]

@ValeraS +1
Иначе получится сильная связанность, ядро будет знать детали, о которых знать не должно.

Можно пример серверного теста реально требующего конфигурирование в отдельном файле?

[EvilBeaver]

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