Тестирование баз данных. Часть 1.

Еще одна неотъемлемая часть систем на платформе 1С:Предприятие это база данных. Если разделить код решения на 2 части - алгоритмы и работа с базой данных, то соотношение будет 30 на 70 в пользу базы данных. Поэтому очень важно протестировать эту функциональность.

Можно смело утверждать, что операции базы данных ограничены это т.н. операции CRUD - create, read, update, delete. Достаточно этих 4х операций чтобы убедится в работоспособности системы? Если система взаимодействует с БД напрямую и мало бизнес-логики, то все эти операции проверить легко. Но база без логики это что-то очень экзотичное.

Платформа 1С берет на себя все взаимодействие с базой данных - индексы, ключи, идентификаторы и т.п., все надежно закрыто object-relational mapping. Более того лицензионное соглашение запрещает обращаться в базу, минуя ORM. Поэтому элементарные операции тестировать бессмысленно, даже если нашел ошибку исправить ее невозможно.
Обработка данных, перед обращением к БД, проходит через "толстый" слой бизнес-логики: проверки, контроли, настройки. Именно эти функции нужно тестировать.

Операцию создание и запись (create) нужно рассматривать отдельно для каждого объекта метаданных:

Создание и запись ссылочных объектов: справочники и документы;
Создание и запись независимых р/св;
Создание и запись не ссылочных объектов: запись в регистры накопления и зависимые р/св можно выполнить только через запись документа.

Аналогично созданию, с точки зрения платформы, выполняются операции изменения и удаления данных.

Примером в данном случае могут быть обработки, создающие новый объект с заполнением реквизитов и запись объекта. В этом случае отработают обработчики события записи в модуля объекта. При таком подходе тестирования возникают сложности с проверкой результатов записи. Очень просто проверить записался объект в БД или нет. Проблемы возникнут если потребуется протестировать, например, выполнение контрольные процедуры при записи. Достаточно сложно будет корректно обработать диалоговые окна, которые выдаст платформа, в случае ошибок.
Аналогично можно выполнить тестирование записи в регистры накопления и зависимые р/св через проведение документа. В данном случае проблемы возникают если требуется проверять запись только в отдельные регистры. Сделать это можно, но очень сложно.

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

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

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

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

Продолжение: Тестирование базы данных. Часть 2.