🤔 [#ВопросОтвет] Недавно в одном из докладов услышал, что докладчик хранит тестовые данные тоже в репозитории в гите. Это нормальная практика? Как обычно принято делать?Хранение тестовых данных в репозитории — один из подходов, имеющих право на жизнь.
В идеале все сценарии сами должны обеспечивать себе подготовку необходимого для их выполнения окружения, включая подготовку данных. Это обеспечивает их независимость от других сценариев, от наличия и корректности данных и таким образом уменьшает их хрупкость.
В таком случае данные обычно либо генерируются «кодом» (в случае VA — шагами сценариев) и наряду с другим кодом помещаются в репозиторий, либо они подгружаются из внешних файлов (например, макетов или json-файлов) — и эти макеты и файлы также хранятся в репозитории.
На курсе
«Автоматизированное тестирование в 1С» мы рассматриваем эти два подхода в последнем разделе «Подготовка и работа с тестовыми данными» и реализуем в рамках практики: делаем так, чтобы написанные нами при выполнении предыдущих домашних заданий сценарии могли запускаться в пустой базе.
Есть целый ряд случаев, например, когда тестовых данных нужно объективно много. Например, при тестировании закрытия месяца. Или при тестировании расчета себестоимости. В макетах такие данные хранить оказывается не очень эффективно с точки зрения поддержки и тогда используются «эталонные базы» — предзаполненные информационные базы 1С.
В некоторых случаях и такие базы, выгруженные в DT-файл, могут храниться в репозитории для упрощения сборочной линии. Опять же, в
нашем курсе как раз такой подход и используется. Это оправдано, т.к. у нас очень маленькая база данных и основная цель, чтобы каждый участник локально имел максимально похожую инфраструктуру без необходимости что-то дополнительно настраивать и тем более устанавливать.
В случае проектов на базе настоящих, не учебных, конфигураций, хранить бинарный файл выгрузки базы данных в git-репозитории не очень эффективно: он занимает несоизмеримо много места (по сравнению с кодовой базой), замедляет работу с репозиторием, раздувает репозиторий.
Но при этом необходимость хранить, версионировать и «доставлять» в сборочную линию такие бинарные файлы как-то нужно.
Такая задача чаще всего решается специальными инструментами: или самодельными (скрипты + файловое хранилище — от FTP до S3), либо специализированными — менеджерами для бинарных репозиториев, такими как NEXUS3, Artifactory и их аналогами.
Подробнее о подходах и приемах подготовки тестовых данных можно узнать у нас на курсе «Автоматизация тестирования в 1С». Но в целом тема подготовки данных — очень большая и сложная и достойна отдельного курса. Для углубления в нее рекомендую несколько ссылок на материалы, в которых разбираются различные схемы и подходы к подготовке и работе с тестовыми данными:
🟢
Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию, Дмитрий Решитко (транскрипт доклада с INFOSTART EVENT 2019)
🟢
«Подготовка данных», Антон Степанов (раздел проекта «Материалы по тестированию в 1С»)
🟢
Раздел «Базы данных» документации инструмента «Тестер» Дмитрия Решитко
🟢
Раздел «Тестовые данные» документации YAxUnit
Это была еженедельная рубрика #ВопросОтвет. Присылайте вопросы по теме тестирования в комментариях к постам или в личные сообщения и я постараюсь на них ответить в формате подобных постов или лично.
🦋
@QA_1C 
