Mocking and Unit Testing Solr and Lucene Index

Нам нужен контроль над данными в производственном индексе solr, и нам нужно, чтобы он был совместим с новыми разработками. В идеале мы хотели бы смоделировать индекс на локальных машинах, запросить с его помощью solr и написать модульные тесты, чтобы запрашивать его для более быстрых итераций.

RamDirectory используется в другом вопросе , чтобы сделать что-то подобное, но вопрос от 2 года назад. Этот пример , кажется, делает именно это (используя FSDirectory вместо RamDirectory). Это правильные подходы к этой проблеме? Есть ли лучшие способы сделать это?

Мы хотели бы написать тесты вроде:

setup mock index;
query mock index;
assert(stuff that should be true);
teardown mock index;

РЕДАКТИРОВАТЬ: Дополнительные сведения:

Мы думали, что создадим индекс, у нас будет простой способ добавления документов без необходимости indexer и остальная часть системы, за исключением, возможно, локальной базы данных, которую мы могли бы держать под контролем версий. В прошлом мы генерировали индекс, а когда возникала несовместимость, мы регенерировали его.

Если мы переиндексируем, мы добавляем много накладных расходов, и насмешка над индексатором не кажется хорошим вариантом, учитывая, что наши indexer содержит много логики обработки данных (например, добавление данных в доступные для поиска поля из базы данных). Наш индексатор подключается к внешней базе данных, поэтому нам тоже нужно поддерживать это. У нас может быть локальная тестовая база данных, как указано выше, которая не имеет больших накладных расходов.

Как только у нас есть тестовая база данных, нам нужно создать индекс, а затем мы можем перейти по второй ссылке выше . Возникает вопрос, как действительно быстро создать индекс для тестирования, скажем, документов размером 1000.

Проблема в том, что нам нужно синхронизировать нашу локальную схему БД с производственной схемой. Схема производства меняется настолько часто, что это становится проблемой. Мы хотели бы иметь достаточно гибкую тестовую инфраструктуру, чтобы справиться с этим - на данный момент подход заключается в том, чтобы каждый раз просто перестраивать базу данных, что медленно и бесит других!