Posted by mkalkbrenner on September 7, 2012 at 6:08pm
4 followers
| Project: | Apache Solr Search Integration |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
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:/...
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| DrupalSolrOnlineWebTestCase.patch | 4.42 KB | Idle | FAILED: [[SimpleTest]]: [MySQL] 503 pass(es), 1 fail(s), and 0 exception(s). | View details |
Comments
#1
The last submitted patch, DrupalSolrOnlineWebTestCase.patch, failed testing.
#2
The last submitted patch, DrupalSolrOnlineWebTestCase.patch, failed testing.
#3
I guess the test bot failed because there's no solr test instance, right?
#4
the tests need to pass here.
#5
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?
#6
DrupalSolrOnlineWebTestCase.patch queued for re-testing.
#7
The last submitted patch, DrupalSolrOnlineWebTestCase.patch, failed testing.
#8
<?php$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 152I 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?
#9
See attachment for my local result.
#10
The tests had a check before that prevented the Solr-dependent tests from being run on the testbot.
#11
OK. What has to be done to accept my patch and to disable the test bot again for my re-written solr-dependent test?
#12
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.
#13
#14
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.
#15
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?
#16
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:
<?php$env_id = apachesolr_default_environment();
$environment = apachesolr_environment_load($env_id);
if (apachesolr_server_status($environment['url'])) {
...
}
?>
#17
566 passes, 0 fails, 0 exceptions, and 131 debug messages
Looks good - committed to 7.x-1.x
#18
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
#19
Committed to 6.x-3.x, found some inconsitencies in 7.x-1.x also so pushing back to 7.x-1.x
#20
#21
committed - marking as fixed
#22
this change is odd and I don't think it needs to be done that way:
+ call_user_func_array('parent::setUp', $args);#23
<?php
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:
<?phpparent::setUp('apachesolr', 'apachesolr_search', 'search', 'apachesolr_multilingual', 'apachesolr_confgen');
?>
#24
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.
#25
like this
#26
need to port fixes #20 and #25
#27
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
#28
That's what it checks out as the dependency? Not offhand, unless there is some bad logic in version comparisons.
#29
I think this is all fixed now via #1790590: Fix DrupalSolrOnlineWebTestCase so it works with any multicore setup
#30