Создание test fixtures

Добрый день, коллеги!

Помогите пожалуйста советом по созданию вспомогательных данных, используемых в тестах? В частности - в автотестах. Опыт тестирования и автотестирования у меня есть - не новичок. Свои варианты решения описанной проблемы - есть, хочется найти им подтверждения/опровержения.

1) Есть web-проект. Биллинговая система. Java.
2) Пишем WebUI автотесты. TestNG, Webdriver все дела
3) Автотестам нужны уникальные данные. Эти данные
а) многоуровневые. Чтобы создать сущность, непосредственно используемую в тесте, необходимо создать нехилую структуру вспомогательных сущностей, от которых нужная сущность зависит
б) похожие. Цепочка КЛАССОВ вспомогательных сущностей во многом повторяется от теста к тесту, при этом оставаясь уникальной (экземпляры классов) для каждого теста

Рассмотрим на примере предметной области сотовой связи. Биллинг абонентов. Предметная область не моя, взял просто для примера, так что в деталях могу приврать.
Тесты:
1) проверить, что некоторая услуга (мобильный инет) включается на сайте. Для этого нужно создать цепочку вспомогательных сущностей: абонент, лицевой счет, периоды действия лицевого счета, периоды действия услуги (мобильный инет), тариф, тарифный план, добавить набор обязательных услуг на тарифный план, услуга 3G или GPRS, от которой зависит услуга "мобильный интернет", и т.д. Собственно тест будет логиниться в аккаунт абонента, переходить на страницу управления тарифным планом, включать нужную услугу и проверять, что она включилась.
2) проверить, что некоторую услугу можно выключить. Для этого нужно иметь всю вышеперечисленную цепочку + плюс включенную услугу

итп.

Сложность в том, что создание этих вспомогательных данных через UI прямо в тесте крайне неэффективно. Потому что:
а) низкая скорость работы через UI
б) сложность написания теста получается довольно высокой - растет вероятность создания ненадёжных тестов, падает скорость создания тестов

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

Вопрос простой: как бы вы решали такую задачу? Возможно есть классическая (принятая) схема её решения, о которой я не знаю. Рассуждения, вопросы приветствуются

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

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

Спасибо. Вариант нормальный, тоже рассматривается. Что мне не нравится здесь:
1) данные отделены от теста - есть риск, что они будут периодически "разъезжаться" после правок data-pump кода
2) при такой схеме тест должен точно знать как идентифицировать нужный ему объект. В случае UI-тестов - это названия сущностей. Соответственно, необходимо жёстко отслеживать на этапе проектирования тестов какие данные будут создаваться. И как-то следить, чтобы они не пересекались. В общем, довольно немало скучной и тупой работы
3) в случае с реальной базой нужен механизм поиска подходящих сущностей. То есть, например, тесту нужен тарифный план, в котором есть включенная и активная опция 3G и при этом нет опции безлимитные SMS и т.п. Нужно нехилое апи для поиска

В системе которую я тестирую есть groovy-консоль, через которую можно выполнять код приложения. Был написан скрипт для создания объекта, а так же наборы оберток для создания конкретных классов. Создание необходимых цепочек осуществляется в датапровайдере. Выполняется это значительно быстрее чем через интерфейс(сводится к остылке 1 формочки на объект, при должном подходе можно достаточно легко очередь за раз выполнять).
Все выглядит достаточно наглядно и просто.
Этот "спасительный" groovy-скрипт становится точкой отказа и корнем проблем. Если из-за него возникнет баг - тест вероятней всего свалится, не пропустим. Значительный плюс - что теперь точка отказа при инициализации одна. На практике проблем с ним не возникает, польза заметна - при конфигурировании через интерфейс были часты сбои(много всплывающих окон, selenium плохо дружит с ними) да и по времени инициализация в разы дольше была.
Стоит заметить, что тесты не совсем на пустой базе начинают работать. В системе сложная и обширная настройка гуя и системы прав - дамп готовится с "настроенной" системы но безка ких либо объектов.

Да, то же не плохо через имеющееся апи или функционал системы заполнить по правилам (например описанных в XML).

В общем мы к такому же варианту пришли. Реализация другая, но суть та же - какой-то отдельный от UI апи. Если есть подходящий стандартный внешний апи приложения, то можно использовать его. Если нет, то создаётся какой-то искусственный сервис, реализующий функции апи.

Попробовал для себя ответить на вопрос "почему не использовать UI-апи?". То есть не создавать вспомогательные объекты через UI:
1) в основном потому что через UI медленнее (кроме того, что UI в принципе медленнее работает (перекачиваемый по сети объем данных, рендеринг, производительность браузера) ещё добавляется избыточность связанная с тем, что кроме собственно действий с объектами время тратится на навигацию)
2) во-вторых, менее стабильный путь (в зависимости от загруженности приложения страницы могут загружаться не стабильно (не стабильно определяться момент загрузки страницы), частые изменения в UI при разработке не способствуют стабильности тестов)
3) в-третьих, в гуе порой приходится обрабатывать всякие левые события и вообще делать больше не относящихся к сути вещей действий от чего достаточно простой код по созданию нескольких сущностей распухает до неподобающих размеров

В общем, всем спасибо, кто принимал участие. Я для себя более-менее понял, что хотел. Надеюсь, кому-нибудь ещё пригодится