Comments on: Using Solr’s AbstractSolrTestCase http://lucasjosh.com/blog/2009/06/28/using-solrs-abstractsolrtestcase/ Sat, 02 Jan 2010 17:56:28 +0000 http://wordpress.org/?v=2.9 hourly 1 By: josh http://lucasjosh.com/blog/2009/06/28/using-solrs-abstractsolrtestcase/comment-page-1/#comment-736 josh Tue, 30 Jun 2009 07:10:46 +0000 http://lucasjosh.com/blog/?p=270#comment-736 Hoss - Thanks for the comment! I can totally see that I'm not necessarily using the test case in its most pure form but the good news is that it is helping our developers write more tests and that's definitely a good thing! I'll take a look at the code and see if I can produce a patch that'll work. Thanks again! Hoss -

Thanks for the comment! I can totally see that I’m not necessarily using the test case in its most pure form but the good news is that it is helping our developers write more tests and that’s definitely a good thing!

I’ll take a look at the code and see if I can produce a patch that’ll work.

Thanks again!

]]> By: Hoss http://lucasjosh.com/blog/2009/06/28/using-solrs-abstractsolrtestcase/comment-page-1/#comment-735 Hoss Tue, 30 Jun 2009 06:51:26 +0000 http://lucasjosh.com/blog/?p=270#comment-735 The abstract test case was really designed to be a base for *Solr* tests, or Solr plugins -- hence the purity of a clean data dir before every test is run. As you say: mocking is definitely the way to go if you want to test the interaction of external systems with Solr (no need to even have Solr running, let alone running inside the actual test case, or with a particular index.) That said: a patch to refactor a new "getDataDir()" method out of setUp so that subclasses could override should be fairly trivial if you'd like to submit one. I don't have the code in front of me, but I think it would even be fairly easy to make it so that if a subclass overrides getDataDir() to return null, then the dataDir from the solrconfig.xml file will be used (just like in a production instance) The abstract test case was really designed to be a base for *Solr* tests, or Solr plugins — hence the purity of a clean data dir before every test is run. As you say: mocking is definitely the way to go if you want to test the interaction of external systems with Solr (no need to even have Solr running, let alone running inside the actual test case, or with a particular index.)

That said: a patch to refactor a new “getDataDir()” method out of setUp so that subclasses could override should be fairly trivial if you’d like to submit one. I don’t have the code in front of me, but I think it would even be fairly easy to make it so that if a subclass overrides getDataDir() to return null, then the dataDir from the solrconfig.xml file will be used (just like in a production instance)

]]>