Хранение тестовых данных

Как определили ранее при разработке автотеста нужны тестовые данные. Тестовые данные в виде справочников, регистров сведений и других настроек должны быть созданы в базе на этапе разработки чтобы при запуске алгоритм сценария смог к ним обратиться. Алгоритм сценария ищет нужные элементы и использует их, как значения реквизитов других справочников или документов. Если элемент не найден его нужно создать, чтобы тест смог выполнится.

Для решения задачи с тестовыми данными нужно решить следующие вопросы:

как и где хранить
как находить
какие данные можно создавать вручную, а какие нужно создавать автоматически

Идеальным местом хранения тестовых данных является код сценария. В этом случае не нужно искать другие артефакты, открывать их и анализировать. Так как в коде невозможно хранить элемент базы данных, поэтому хранится описание элемента данных в виде универсальной коллекции - структуры, списка значений или соответствия. У таких коллекций можно задать реквизит в виде уникального идентификатора и его значения.

В ходе исполнения сценария такое текстовое описание элемента нужно превратить в элемент базы данных. Как правило это ссылочный элемент, т.е. элемент справочника. Получение элемента по текстовому описанию возможно через поиск. Для поиска можно использовать код или наименование. Код не подходит, т.к. код имеет ограниченную длину и нужно "вручную" обеспечить его уникальность. При использовании наименования, его можно сформировать нужным образом и потом найти элемент в базе "глазами" при разборе ошибок. Основное требование к наименованию это возможность однозначной идентификации элемента в базе. В UI-тестах достаточно наименования чтобы выбрать элемент справочника.

Не всегда возможно использовать наименование поэтому для идентификации можно использовать комбинации реквизитов.

Еще один вариант это внутренние ссылки. Но их использование связано с дополнительными трудностями, в частности код становится нечитабельным. Также при использовании ссылок в UI-тестах требуется дополнительное преобразование. Так как при тестировании используется 2 приложения, то нужно прилагать дополнительные усилия чтобы найти нужный элемент:

использовать одну база, но запускать в 2х разных режимах;
использовать специальный интерфейс, с помощью которого тестирующее приложение по ссылке создает или находит объект.

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

Без ответа пока остается вопрос - какие данные должны быть уникальными для сценария, а какие можно использовать во всех сценариях.

Рассмотрим пример хранения и идентификации на примере сценария заполнения документа Поступление товаров и услуг. Код ниже описывает элемент справочника Контрагенты и шапку документа Поступление товаров и услуг:

УИД = "123456";

Контрагент = Новый Структура(); 
Контрагент.Вставить ("Наименование", "Контрагент" + УИД); 
Контрагент.Вставить ("ИНН", "0987654321"); 

ПТиУ = Новый Структура(); 
ПТиУ.Вставить ("Контрагент", "Контрагент" + УИД); 
ПТиУ.Вставить ("ДоговорКонтрагента", "Договор" + УИД); 
ПТиУ.Вставить ("Склад", "Основной");

Этот код, используя описание элементов тестовых данных, заполняет реквизиты объектов:

Поле = ФормаЭлемента.НайтиОбъект( Тип("ТестируемоеПолеФормы"),, "Наименование" ); 
Поле.ВвестиТекст( Контрагент.Наименование ); 
Поле = ФормаЭлемента.НайтиОбъект( Тип("ТестируемоеПолеФормы"),, "ИНН" ); 
Поле.ВвестиТекст( Контрагент.ИНН ); 

Поле = ФормаДокумента.НайтиОбъект(Тип("ТестируемоеПолеФормы"), "Контрагент");
Поле.ВвестиТекст( ПТиУ.Контрагент);
Поле = ФормаДокумента.НайтиОбъект(Тип("ТестируемоеПолеФормы"), "ДоговорКонтрагента");
Поле.ВвестиТекст( ПТиУ.ДоговорКонтрагента);
Поле = ФормаДокумента.НайтиОбъект(Тип("ТестируемоеПолеФормы"), "Склад");
Поле.ВвестиТекст( ПТиУ.Склад );