xUnitFor1C
xUnitFor1C copied to clipboard
xDrivenDevelopment
Добавление конфигурационных параметров для настройки тестов
Есть тесты, которые являются универсальными для многих конфигураций. Нужна возможность их настраивать, чтобы разделить реализацию тесты и настройку под конкретную конфигурацию.
Например, для тестов открытия форм конфигурации нужно задавать исключения форм, которые не требуется тестировать #179 Для тестов пользователей с ограниченными правами нужно задавать список пользователей и/или наборы прав, с которыми нужно запускать эти тесты.
Предлагаю следующее:
- при тестировании возможно указать настроечный xml-файл, в котором будут храниться индивидуальные настройки для тестов
- при интерактивном тестировании файл можно выбрать вручную
- при запуске из командной строки будет добавлен спец.параметр
config-file, указывающий на путь к файлу настройки - формат хмл-файла - это простое дерево, где узлом является имя/идентификатор тестового набора, а листьями являются конкретные параметры для тестирования
- в ядро xUnitFor1С (для сервера и УФ-клиента) будет добавлен набор методов для получения параметров настройки
Обсудим?
Ты в юнит тесты пытаешься засунунть интеграционные тесты.
Простая генерилка текста bdd позволяет тебе тебе уже получить разлчиные настройки для сценариев. В частности у меня так выглядит тестирование открытия форм для различных подсистем.
и код тестовой обработки вот так выглядит
@pumbaEO Женя, я уже давно не говорю "юнит-тесты", а в нашем проекте, да и в разработке для 1С работаю над различными видами тестов. Сам знаешь, в рамках 1С очень сложно сделать "чистые" юнит-тесты :)
И настройка тестов под конкретную конфигурацию ИМХО не является злом :)
подход с БДД очень интересен, и мы к нему движемся. Картинки у тебя интересные.
Я фактически и подготовил релиз 3.0 как релиз, позволяющий нашему проекту работать со сценарными тестами и БДД.
В БДД есть очень полезные фишки, например, повторное использование шагов мне очень нравится. Но пока не все проблемы использования решены :(
Например, пока что мне очень не нравится то, что нужно юзать некие генераторы текста/кода, это замедляет процесс разработки/тестирования. Наверняка, со мной ты и кто-то еще не согласятся, но это мое текущее видение.
Женя, опиши, пожалуйста, в чем сейчас плюсы и минусы твоей доработки для Огурца. Напиши свое видение, как можно юзать эту доработку. Жду, очень интересно.
- Работает в linux и windows.
- Тест обратно совместим с юнит тестами, т.е. когда идет генерация сценария то формирую только процедуру "ПолучитьСписокТестов" и туда в массив добавляю все шаги (хоть они и могут повторятся).
- Повторно используемый код, т.е. приоритет поиска процедуры для выполнения ищу по текущей фиче, если не нахожу, то ищу по всему дереву тестов. Позволяет мне вынести библиотечные функции и тесты в отдельные обработки и использовать их повторно.
Пока одно замечание скорость, за счет парсинга и таймаутов время теряется на обмен данными, а не на тесты.
@pumbaEO по БДД понятно.
А что еще ты можешь сказать по конфигурационной настройке? Нужно вообще? если нет, как реализовать указанную доп.настройку тестов (без БДД) ? если да, что скажешь по формату настройки? может быть, предложишь другие варианты?
Кто еще что может добавить? @allustin ? @kuntashov ? @wizi4d ? @ValeraS ?
Мне кажется это функциональность самого теста а не xUnitFor1С. Что мешает тест-обработке, при заполнении списка тестовых методов, прочитать свой конфигурационный файл и выполнить необходимые настройки?
Согласен про функциональность теста, но в режиме УФ на сервере у формы нет доступа к файлу на клиенте, т.е. тест тупо свои настройки прочитать не сможет :(
Правда, это можно сделать в ПолучитьСписокТестов при его вызове с клиента.
Но чисто серверный тест, который определен только в модуле обработки, даже при чтении внутри ПолучитьСписокТестов файл с клиента не получит, т.к. этот метод будет вызван только на сервере :(
@ValeraS +1 Иначе получится сильная связанность, ядро будет знать детали, о которых знать не должно.
Можно пример серверного теста реально требующего конфигурирование в отдельном файле?
Нужен конкретный use-case - для чего будет использоваться данный функционал. Просто, имхо, проблем больше, чем получаемой выгоды
Злые вы :) В процессе обсуждения с Андреем (@EvilBeaver ) я уже понял, что оба описанных мной сценария выполняются на клиенте и нет проблемы с доступом к файлу.
Мне кажется это функциональность самого теста а не xUnitFor1С. Что мешает тест-обработке, при заполнении списка тестовых методов, прочитать свой конфигурационный файл и выполнить необходимые настройки?
Поясню свои размышления при создании задачи - функционал (чтение настроек) может юзаться в нескольких сценариях. А известно, что если функционал пересекается в нескольких местах, почти всегда лучше его собрать в одном месте (например, в ядре или в плагинах) и исключить дублирование. Так и возникла эта задача
Вот за что я и люблю коллективную разработку - захочешь сделать одно, тебя или собьют с пути, направив на правильный :) , или дадут информацию к размышлению, или расскажут, что нужная фича уже давно реализована :)
Я же упорный :) Поэтому набор следующих вопросов:
- где должен находиться этот конфигурационный/настроечный файл?
- Если это внешняя обработка, напрашивается мысль положить файл настройки рядом с обработкой-тестом. Но в этом случае опять идет смешение кода исходников и кода настройки, что мне не очень нравится.
- А если это встроенная обработка, где должен находиться файл настройки?
devops - все есть код, т.е. я пока не вижу проблем файла настроек рядом с обработкой. Если встроенная, тогда в макете.
И опять таки, универсального кода не сделаешь, тест у тебя работает на том коде который сейчас в конфигурации, настройки тоже для определенного вида теста, почему тогда ты уверен, что настройки можно будет между разными конфигурациями тасовать?
Настройки индивидуальны для ИБ, а вот код теста независим от конфы и хочется именно тест распространять как продукт, релиз
пт, 12 Июн 2015, 9:38, Shenja Sosna [email protected]:
devops - все есть код, т.е. я пока не вижу проблем файла настроек рядом с обработкой. Если встроенная, тогда в макете.
И опять таки, универсального кода не сделаешь, тест у тебя работает на том коде который сейчас в конфигурации, настройки тоже для определенного вида теста, почему тогда ты уверен, что настройки можно будет между разными конфигурациями тасовать?
— Reply to this email directly or view it on GitHub https://github.com/xDrivenDevelopment/xUnitFor1C/issues/513#issuecomment-111380087 .