Ну пример можно найти в исходниках, а детальное описание - в статье в блоге. Я ведь выше не зря намекал на ссылку в БЗ. 
Все предельно просто и понятно. Говорим хибернейту, что данный класс - сущность, ссылающаяся на таблицу USERS
, которая в свою очередь содержит колонки email
/ password
.
Но вам ведь для одного теста не нужны все записи таблицы, правильно? Вам нужен только 1 юзер. Я не беру сейчас во внимание сценарии, когда вам нужно будет прогнать один и тот же тест с разными данными. Там будет немного другая стратегия. Но в базовом случае, делать полную выборку из таблицы - не оптимально.
А зачем хранить данные для конкретной формы? Слишком велик риск разброса данных, относящихся к совершенно разным сущностям, что может повлечь за собой постоянные изменения многих участков кода / БД. Лично для себя нашел эффективным вариант создания бизнес сущностей + так называемых датасетов для конкретного теста. При этом, датасеты оперируют все теми же бизнес сущностями. К примеру, чтобы осуществить платеж, мне нужно залогиниться в систему, выбрать профайл, загрузить / подписать / отправить платежный документ, верифицировать факт завершения транзакции / сопоставить input / output платежные реквизиты / суммы. Т.е. бизнес сущностями (имеющими реальный value) тут будут выступать: юзер, профайл, файл, платежная карта. Датасет же будет комбинировать в себе все эти сущности (ссылаясь при этом только на конкретные записи, нужные тесту). На этом этапе могут отличаться особенности реализации: т.е. вы все можете организовать на уровне самой БД, либо же производить все манипуляции в коде. It's up to you. Но потенциальные изменения будут требовать минимум времени и вмешательств в структуру базы.