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