nfl*_*cco 7 lucene testing solr unit-testing ramdirectory
我们需要控制生产solr索引中的数据,我们需要它与新开发兼容.理想情况下,我们想在本地机器上模拟索引,用solr查询并编写单元测试来查询它以便更快地迭代.
RamDirectory在另一个问题中用于做类似的事情,但问题是从2年前开始.这个例子看起来就是这样(使用FSDirectory而不是RamDirectory).这些是解决这个问题的正确方法吗？有没有更好的方法来做到这一点？
我们想编写如下测试:
setup mock index;
query mock index;
assert(stuff that should be true);
teardown mock index;
编辑:其他详细信息:
我们的想法是我们会构建一个索引,有一个简单的方法来添加文档而不需要索引器和系统的其余部分,除了我们可以保留在版本控制中的本地数据库.在过去,我们生成了一个索引,当出现不兼容性时,我们重新生成它.
如果我们重新索引,我们会增加很多开销,并且假设我们的索引器包含大量数据处理逻辑(比如将数据添加到数据库中的可搜索字段),模拟索引器似乎不是一个好选择.我们的索引器连接到外部数据库,所以我们也需要支持它.我们可以有一个如上所述的本地测试数据库,几乎没有开销.
一旦我们有了一个测试数据库,我们需要建立一个索引,然后我们可以关闭上面的第二个链接.问题变成了我们如何真正快速地构建索引以进行测试,比如大小为1000的文档.
这样做的问题是我们需要保持本地数据库模式与生产模式同步.生产模式经常变化,这是一个问题.我们希望有一个足够灵活的测试基础设施来处理这个问题 - 到目前为止,这种方法只是每次都重建数据库,这很慢并且让其他人生气!
如果您使用的是Solr,我甚至不会为模拟或模拟而烦恼(即不要更改其配置).
而是编写一个设置solr索引的集成测试.设置只是为了像往常一样索引数据.您可能希望您的开发人员运行自己的solr.
我不会太担心速度,因为solr索引速度令人难以置信(对于我们的环境,在不到30秒的时间内就有100,000个文档......事实上,瓶颈正在从数据库中提取数据).
所以你的模拟索引应该只是生成数据的一小部分,你将索引到solr(你可以用@BeforeClass为每个TestCase类做一次).
编辑(根据您的编辑):
我会告诉你我们是怎么做的(以及我是如何看到别人这样做的):
我们有一个开发模式/ db和生产模式/ db.当开发人员正在开发工作时,他们只需复制"构建机器"开发数据库并在本地恢复它.该数据库比生产数据库小得多,是测试的理想选择.您的生产数据库应该与开发数据库模式明显不同(如果是这种情况,请进行更小的更改并更频繁地发布.)