Mocking и модульное тестирование Solr и Lucene Index - PullRequest
6 голосов
/ 27 июля 2011

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

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

Мы бы хотели написать такие тесты, как:

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

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

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

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

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

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

1 Ответ

5 голосов
/ 28 июля 2011

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

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

Я бы не стал сильно беспокоиться о скорости, потому что solr индексирует невероятно быстро (100 000 документов менее чем за 30 секунд для нашей среды ... влияют на бутылочное горлышкоизвлекает данные из базы данных).

Таким образом, ваш фиктивный индекс должен быть просто небольшим подмножеством производственных данных, которые вы будете индексировать в solr (вы можете сделать это один раз для каждого класса TestCase с помощью @BeforeClass).

РЕДАКТИРОВАТЬ (на основе ваших правок):

Я расскажу вам, как мы это делаем (и как я видел, как это делают другие):

У нас есть схема разработки / БД и производственная схема / БД.Когда разработчики работают над чем-то, они просто делают копию базы данных разработки «сборки машин» и восстанавливают ее локально.Эта база данных намного меньше производственной базы данных и идеально подходит для тестирования.Ваша производственная база данных не должна сильно отличаться от вашей схемы разработки (делайте меньшие изменения и выпускайте чаще, если это так).

...