Управление тестовыми данными

Начало: Тестирование баз данных. Часть 1., Тестирование базы данных. Часть 2.

База данных предназначена для того чтобы хранить данные. Тестам же нужна чистота. Сценарию при выполнении не должны "мешать" старые данные или данные созданные другими сценариями.
Существует несколько подходов, которые решают вопрос:

1. Выполнять сценарий в транзакции
2. Удалять данные по окончанию сценария
3. Восстанавливать базу перед запуском сценария
4. Создавать уникальные данные при каждом запуске

Транзакция самый плохой способ решения вопроса. Суть в том, что создание и обработка данных выполняется в транзакции, а в конце сценария транзакция откатывается и данные не сохраняются в базе. База чистая, но непонятно как анализировать результат теста. Использование такого подхода требует эталонную базу.

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

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

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

Создание "уникальных" данных при каждом запуске сценария имеет свои особенности. В данном случае также необходима эталонная база, но ее назначение очень ограничено. Более корректно такую базу называть начальной, т.к. она содержит минимальный набор данных и основные настройки. Описание создаваемых тестовых данных хранится вместе с кодом сценария.
Ключевым параметром является уникальный идентификатор, который определяет уникальность тестовых данных в пределах одной базы данных. Идентификатор используется при поиске ссылочных данных, как значения реквизитов. Данные накапливаются в базе и это скорее преимущество чем недостаток. Через некоторое время база наполняется историческими данными и для тестирования можно использовать подход - сравнение новых данных с историческими. Все эти проблемы и их решения хорошо раскрыл коллега в своем докладе: https://infostart.ru/1c/articles/1243144/

Продолжение: Варианты тестового окружения