Подготовка данных¶
Есть несколько способов подготовки данных, каждый из которых имеет свои плюсы и минусы. Подхода без минусов пока найти не удалось.
Пустая база¶
На пустой или почти пустой дт (Есть пользователь с отключенной защитой и константа для отключения блокировки БСП) накатывается cf и выполняется первоначальная инициализация средствами конфигурации. Данные готовятся тестами.
Плюсы:
- Простая реализация и подготовка.
- Легко тиражируется. Если есть 10 блоков тестов, которые стартуют с пустой базы, то можно ее подготовить один раз и дальше копировать каталог для запуска там тестов.
- Нет неожиданных данных.
- Есть проверка заполнения НСИ. Ведь проверяется не только функционал подсистемы, но и подготовка данных.
- Устойчиво к изменению метаданных НСИ. Если меняются метаданные в НСИ, то или нужно немного поправить тест, либо он сразу начинает работать (если изменений на форме нет).
- Версионирование. Все данные могут хранится в git с возможностью отката, слияния и понимания происходящего.
Минусы:
- Если нужно много данных, то готовить их тестами может быть неоправдано долго.
- Нужные данные уже могут быть в какой-то базе, а написать тесты по заполнению этих данных может занять даже больше времени, чем проверка основного функционала.
Этот вариант хорошо подходит для небольших баз, в которых просто нет много данных и для тестирования небольших самостоятельных подсистем, когда в любом случае нужно набивать данные, чтобы проверить их заполнение.
Загрузка данных¶
Пустая база и загрузка НСИ и документов осуществляется каким-либо пакетным образом - обменом, из файла, из табличного документа, шагами пакетной загрузки.
Плюсы:
- Легко тиражируется. Можно использовать ту же подготовленную пустую базу, а потом в нее импортировать все нужное.
- Быстрая загрузка нужных данных.
- Проверка механизмов загрузки, если используются они.
- Все данные могут хранится в git.
Минусы:
- Подготовка данных может занять очень много времени. Нужно или выгружать данные откуда то, или готовить файлы из которых будет выполняться импорт.
- Инструмент по импорту может не грузить так, как нужно и придется писать/дописывать что-то свое.
- Изменение метаданных может привести к очень трудоемкому процессу подготовки/переподготовки файлов. Нужно или менять файлы, или процедуры импорта.
- Нужно писать тесты на заполнение НСИ.
- Если уже есть база с нужными данными, то эти данные все равно нужно выгружать в файлы.
- При пакетной загрузке могут создаваться битые объекты. Это может приводить к неожиданным ошибкам при тестировании.
Вариант подходит при наличии готовых инструментов по импорту НСИ, достаточно стабильным метаданным и наличии тестов, которые отдельно проверяют работоспособность создания этой НСИ.
Эталонная база из дт¶
База, в которой выполнялось ручное тестирование, подготовленная демо-база или база, в которой вручную специально заполнили нужные данные. Эта база выгружается в дт, а при разворачивании окружения для тестирования - как то доставляется в новую базу, и в нее загружается cf.
Плюсы:
- Базовая НСИ уже есть при старте написания тестов. А может данные уже есть на момент начала написания тестов.
- Можно подготовить такие данные, которые сложнее подготовить другими способами. Загрузить коды маркировки из ЧЗ, загрузить НСИ из Меркурия, отключить обмены и иметь стабильные данные для тестов.
- Если было изменение метаданных по НСИ, то механизм миграции это учтет. Или мы найдем, что механизм миграции не работает.
Минусы:
- Дт нужно доставлять другим способом, в git уже не положить
- Нужно писать тесты на заполнение НСИ.
- Изменение НСИ не версионируется. Доработка базы под новые блоки или изменение под существующие не подпадает под версионирование и можно не суметь откатить изменения.
Единая база для тестов¶
База, которая уже есть, уже готовая и на которой гоняются тесты. База обычно клиент-серверная.
Плюсы:
- Уже все готово.
- Легко приготовить данные.
- Механизм миграции обеспечит корректное изменение метаданных.
- Доставлять дт не надо, база уже есть и готова.
Минусы:
- Критичным становится подготовка данных и чистка за собой. Если создать номенклатуру и потом сразу упасть, то новый заход должен обязательно удалить номенклатуру с предыдущего раза.
- Обновление на новый cf становится сложнее. Скорей всего в этой базе постоянно крутятся тесты и может даже от разных команд.
- Нужно писать тесты на заполнение НСИ.
- Данные от других тестов могут повлиять на текущий блок.
- Изменение НСИ не версионируется
Выгрузка продуктовой базы¶
Получение дт из прода и назначение ее эталонной базой.
Плюсы:
- Много реальных данных, на которых и нужно тестировать.
- см. Эталонная база из дт
Минусы:
- Для продуктовой разработки не подходит.
- Размер базы может быть слишком большим.
- Вопрос безопасности данных.
- Нужно писать тесты на заполнение НСИ.
- Могут быть неожиданные данные, которые ломают работающие тесты, такие как битые ссылки.
- см. Эталонная база из дт
Заполнение эталонной базы¶
Берется пустая база или слабозаполненная эталонная, на нее накатывается cf. Потом в этой базе выполняются блоки тестов по наполнению данными. По завершению наполнения база выгружается в дт. Этот дт может выступать как эталонный для основных тестов. Этот же дт может быть использован в качестве демо-базы.
Вначале можно вообще в качестве начального дт использовать выгрузку с прода, а потом заменять часть данных на заполнение, пока все данные не начнут готовится тестами.
Плюсы:
- Легко тиражируется.
- Нет неожиданных данных.
- Базовая НСИ уже есть при старте написания тестов.
- Проверяется не только функционал подсистемы, но и подготовка данных. И может быть отключено.
- Устойчиво к изменению метаданных НСИ.
- Версионирование.
- Готовая демо-база
Минусы:
- Готовить данные чуть сложнее
- Нужно модернизировать пайплайн, чтобы он умел и готовить базу и использовать уже подготовленную.
- Нужно доставлять дт.
По совокупности плюсов и минусов этот вариант выглядит наиболее удобным при подготовке тестов.