Closed (fixed)
Project:
Apache Solr Search
Version:
6.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
7 Sep 2012 at 18:08 UTC
Updated:
10 Aug 2014 at 11:00 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #3
mkalkbrennerI guess the test bot failed because there's no solr test instance, right?
Comment #4
pwolanin commentedthe tests need to pass here.
Comment #5
mkalkbrennerHow 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?
Comment #6
mkalkbrennerDrupalSolrOnlineWebTestCase.patch queued for re-testing.
Comment #8
mkalkbrennerI 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?
Comment #9
mkalkbrennerSee attachment for my local result.
Comment #10
pwolanin commentedThe tests had a check before that prevented the Solr-dependent tests from being run on the testbot.
Comment #11
mkalkbrennerOK. What has to be done to accept my patch and to disable the test bot again for my re-written solr-dependent test?
Comment #12
pwolanin commentedLook at the existing tests which were working. They all have:
to skip running if the server is not available.
Comment #13
pwolanin commentedComment #14
mkalkbrennerthis 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.
Comment #15
pwolanin commentedYes, 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?
Comment #16
mkalkbrennerI 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:
Comment #17
nick_vh566 passes, 0 fails, 0 exceptions, and 131 debug messages
Looks good - committed to 7.x-1.x
Comment #18
nick_vhNeeded 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
Comment #19
nick_vhCommitted to 6.x-3.x, found some inconsitencies in 7.x-1.x also so pushing back to 7.x-1.x
Comment #20
nick_vhComment #21
nick_vhcommitted - marking as fixed
Comment #22
pwolanin commentedthis change is odd and I don't think it needs to be done that way:
Comment #23
mkalkbrennerDrupalWebTestCase::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:
Comment #24
pwolanin commentedhttp://api.drupal.org/api/drupal/modules%21simpletest%21drupal_web_test_...
so we should be able to just do:
Though, that suggests we should be more careful and check if $args[0] is an array.
Comment #25
pwolanin commentedlike this
Comment #26
pwolanin commentedneed to port fixes #20 and #25
Comment #27
mkalkbrennerAh, 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
Comment #28
pwolanin commentedThat's what it checks out as the dependency? Not offhand, unless there is some bad logic in version comparisons.
Comment #29
pwolanin commentedI think this is all fixed now via #1790590: Fix DrupalSolrOnlineWebTestCase so it works with any multicore setup
Comment #30
nick_vhComment #31
mkalkbrenner#20 and #25 are missing in 6.x-3.x
Comment #32
mkalkbrennercommitted to git