Unit тестирование и Jackrabbit (JCR)

Вот есть такая замечательная поделка как Jackrabbit - кладязь сюрпризов и неожиданностей. И захотелось как то пописать тесты на классы, которые работают с этим Jackrabbit-ом.

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


Начали думать....

Вариант №1. Сделать "по пацански" - сэмулировать репозиторий

Посмотрели сколько сущностей предоставляет репозиторий - пользоваться mock-ами сразу перехотелось.

Вариант №2. "Условия приближенные к боевым" - подсунуть "живой" репозитарий

Создали "тестовый" repository.xml. который использует Derby DB в качестве хранилища.
Плюсы:
а) Derby DB хранит базу в локальных фалах, так что нету необходимости подымать, настраивать и привязывться к чему то большому (типа MS SQL, Oracle и т.д.)
б) репозиторий и БД хранятся в одной директории, а значит удалив папку можно "обнулить" все хранилище. Эти операции (создания\удаления репозитория) можно выполнять до и после выполнения тестов.
Минусы:
а) создание и удаление файлов репозитория и БД занимает некоторое время - пару секунд. Но этого достаточно, чтобы время выполнения всей группы тестов сделать порядка 20-30 сек. - а это уже серьезное неудобство.

Вариант №3. "Меняем память на производительность"

Если заменить использовать InMemPersistenceManager и MemoryFileSystem, то можно процедуру инициализации и уничтожения хранилища свести к 100-500 мсек - и это как раз то, что надо. В результате создали класс RepositoryProvider со следующей логикой:

При создании:
1. Создать временную папку, скопировать туда repository.xml и nodetypes.xml
2. Поднять репозиторий и создать нужный workspace
3. импортировать nodetypes.xml

При удалении:
1. Сделать shotdown репозиторию.
2. Удалить временную папку (папку и 2 файла).