As discussed with Nick in Munich, I refactored the DrupalSolrOnlineWebTestCase class which sets up a test index. Using my patch attached the new AbstractDrupalSolrOnlineWebTestCase could be used by others as base class to test their add-ons for Apache Solr Search Integration.

Here you can see how Apache Solr Multilingual will make use of it:
http://drupalcode.org/project/apachesolr_multilingual.git/blob/9568ec6:/...

Comments

Status: Needs review » Needs work

The last submitted patch, DrupalSolrOnlineWebTestCase.patch, failed testing.

The last submitted patch, DrupalSolrOnlineWebTestCase.patch, failed testing.

mkalkbrenner’s picture

Status: Needs work » Reviewed & tested by the community

I guess the test bot failed because there's no solr test instance, right?

pwolanin’s picture

Status: Reviewed & tested by the community » Needs work

the tests need to pass here.

mkalkbrenner’s picture

How can we achieve that?
If I run the test locally, everything works fine!
Are you sure that a solr test instance is available for the test bot?

mkalkbrenner’s picture

Status: Needs work » Needs review

DrupalSolrOnlineWebTestCase.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, DrupalSolrOnlineWebTestCase.patch, failed testing.

mkalkbrenner’s picture

Status: Needs work » Needs review
$this->assertTrue($this->solr->ping(), "The Server could be Pinged");
Fatal error: Call to a member function ping() on a non-object in /var/lib/drupaltestbot/sites/default/files/checkout/sites/default/modules/apachesolr/tests/solr_index_and_search.test on line 152

I did not change the logic of the tests. I just split an additional base class which could be used by others.
In my local setup, all tests pass.

For me it seems that the test instance has no local jetty server to access.

What can we do to debug this?

mkalkbrenner’s picture

StatusFileSize
new17.22 KB

See attachment for my local result.

pwolanin’s picture

The tests had a check before that prevented the Solr-dependent tests from being run on the testbot.

mkalkbrenner’s picture

OK. What has to be done to accept my patch and to disable the test bot again for my re-written solr-dependent test?

pwolanin’s picture

Look at the existing tests which were working. They all have:

if (apachesolr_server_status($environment['url'])) {

to skip running if the server is not available.

pwolanin’s picture

Status: Needs review » Needs work
mkalkbrenner’s picture

Status: Needs work » Needs review
StatusFileSize
new5.55 KB

this is really crazy: let the tests succeed if they could not be run!

But ok, here's the patch that satisfies the drupal.org test bot.

pwolanin’s picture

Yes, a bit crazy - but I think it's the only hack-around Nick found.

Could probably test once in setUp instead of in each place and set a class variable?

mkalkbrenner’s picture

Could probably test once in setUp instead of in each place and set a class variable?

I don't think so. You have to check in every single test, because the only way to prevent the tests from running is to let the setup fail.

Therefore I created the instance variable which is set in setUp and is easier to check than doing these three lines every time:

$env_id = apachesolr_default_environment();
$environment = apachesolr_environment_load($env_id);
if (apachesolr_server_status($environment['url'])) {
...
}
nick_vh’s picture

Version: 7.x-1.x-dev » 6.x-3.x-dev
Status: Needs review » Patch (to be ported)

566 passes, 0 fails, 0 exceptions, and 131 debug messages

Looks good - committed to 7.x-1.x

nick_vh’s picture

Status: Patch (to be ported) » Needs review
StatusFileSize
new9.16 KB

Needed some small fixes for 6.x-3.x to work properly

without solr, 626 passes, 0 fails, and 0 exceptions
with solr, 660 passes, 0 fails, and 0 exceptions

nick_vh’s picture

Version: 6.x-3.x-dev » 7.x-1.x-dev
Status: Needs review » Needs work

Committed to 6.x-3.x, found some inconsitencies in 7.x-1.x also so pushing back to 7.x-1.x

nick_vh’s picture

Status: Needs work » Needs review
StatusFileSize
new3.17 KB
nick_vh’s picture

Status: Needs review » Fixed

committed - marking as fixed

pwolanin’s picture

Status: Fixed » Needs work

this change is odd and I don't think it needs to be done that way:

+    call_user_func_array('parent::setUp', $args);
mkalkbrenner’s picture

Status: Needs work » Needs review
class AbstractDrupalSolrOnlineWebTestCase extends DrupalWebTestCase
{
   function setUp() {
     $args = func_get_args();
     $args[] = 'apachesolr';
     $args[] = 'apachesolr_search';
     $args[] = 'search';

     call_user_func_array('parent::setUp', $args);
  }
}

DrupalWebTestCase::setUp() expects the modules to be enabled as separate arguments. Test Cases extending AbstractDrupalSolrOnlineWebTestCase might add more modules than 'apachesolr', 'apachesolr_search' and 'search' which are required at least. For example 'apachesolr_multilingual' or 'apachesolr_confgen'.

I don't know any different way than this implementation to call parent::setUp() with static and dynamic patameters that ends in a call like this:

  parent::setUp('apachesolr', 'apachesolr_search', 'search', 'apachesolr_multilingual', 'apachesolr_confgen');
pwolanin’s picture

http://api.drupal.org/api/drupal/modules%21simpletest%21drupal_web_test_...

  // Install modules needed for this test. This could have been passed in as
  // either a single array argument or a variable number of string arguments.
  // @todo Remove this compatibility layer in Drupal 8, and only accept
  // $modules as a single array argument.
  $modules = func_get_args();
  if (isset($modules[0]) && is_array($modules[0])) {
    $modules = $modules[0];
  }

so we should be able to just do:

parent::setUp($args);

Though, that suggests we should be more careful and check if $args[0] is an array.

pwolanin’s picture

StatusFileSize
new1.47 KB

like this

pwolanin’s picture

Version: 7.x-1.x-dev » 6.x-3.x-dev
Status: Needs review » Patch (to be ported)

need to port fixes #20 and #25

mkalkbrenner’s picture

Ah, I was not aware that DrupalWebTestCase accepts a single array now.

BTW any idea why the d.o test bot uses apachesolr 7.x-1.0-beta19? see http://qa.drupal.org/pifr/test/343468

pwolanin’s picture

That's what it checks out as the dependency? Not offhand, unless there is some bad logic in version comparisons.

pwolanin’s picture

Status: Patch (to be ported) » Fixed
nick_vh’s picture

Status: Fixed » Closed (fixed)
mkalkbrenner’s picture

Issue summary: View changes
Status: Closed (fixed) » Needs work

#20 and #25 are missing in 6.x-3.x

mkalkbrenner’s picture

Status: Needs work » Fixed

committed to git

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.