Установка значений констант и константы в генераторе макета

[bf0rce]

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

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

[pumbaEO]

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

p.s.: опиши use case, чего этим хочешь добиться и какие случаи поможет тебе протестировать.

[asheichenko]

Добавлю от себя, существует сценарий: необходимо тестировать поведение документов при партионном учете и при РАУЗ. Т.е. сейчас нам необходимо в каждом тесте проведения документов устанавливать состояние системы по определенному набору настроек, проверить поведение документа в зависимости от этих настроек. При создании теста другого документа приходится копировать макет установки состояний системы.
Может стоит выделить какой-то отдельный метод или обработку для повторного использования макетов установки состояний системы в других тестах.

[ANemcov]

А почему не хотите просто разворачивать два макета: первый с константами, а второй - с документами?

[asheichenko]

Так тесты должны быть независимыми.

[bf0rce]

@pumbaEO, кейса у меня два.

1. Была написана некая новая подсистема. Вся подсистема подвязана на функциональную опцию и по умолчанию спрятана. Соответственно, я хочу проверить, что при выключенной константе у меня не отрабатывает код в подписках на события; а при включенной константе все работает. Хочу также проверять, что подсистема и ее составные элементы не доступны в интерфейсе (этого я пока не делал вовсе). А еще желательно проверить, что при выключении уже включенной ранее константы происходят дополнительные действия, связанные с очисткой регистров, выключением регламентных заданий и пр.
2. Теперь применительно к конфигурации в целом. Сейчас я вынужден разворачивать ее из dt-шника, так как устанавливать константы ручками в коде - лень. Соответственно, если бы это было тиражное решение, то я не проверяю этап начальной настройки, например, БСП. Все это не гибко. Желаемый для меня вариант - загрузка cf-ника в базу, выполнение псевдо-теста, у которого в макете нужные мне константы, а далее прогон стандартных тестов, которые заточены под эти константы.

[artbear]

Тут можно использовать общий подход к организации тестовой базы:

1. есть файл конфигурации, на его базе создаем пустую ИБ
2. у любой ИБ есть некий набор константных значений/значений по умолчанию (валюты, банки).
   этот набор мы заполняем либо выполнением спец.обработки-теста (заполняются все настройки)
   либо кодом первоначального запуска системы
3. далее есть/бывает набор тестовых данных по умолчанию (например, мы в тестах постоянно пользуемся одной/двумя организациями)
   этот набор заполняется спец.обработкой-тестом
4. и есть наборы данных, уникальные для каждого теста
   эти наборы должны создаваться в каждом отдельном тесте

[artbear]

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

[bf0rce]

Спасибо. Принцип ясен.