We're using @perusio's drupal-with-nginx as our baseline configuration, and have an initiative to beef up our testing and test automation infra. Running tests from some or all of the test suite produces a healthy number of fails... many/most of which are to be expected, given the configuration.
As an example, there are tests in the system module that check direct access index.php, etc, and tests for the update system... and this nginx config blocks direct access to php scripts and may be set up with the imperative that updates must be done via drush (not update.php), so, such tests unsurprisingly report as failed.
So just wondering how the great minds in this here awesome group of people have dealt with this, or worked around it, to keep the build monkey happy?
Comments
You need to adapt the tests for your setup
and probably patching core (using the proper process of submitting patches and not killing kittens) is the good option.
Why the heck does it need direct access to
index.php. I fail to see the logic. You can give access toupdate.phpbut I find it a bad way to do updates. It's much more amenable to industrialization of deployments to use drush and to rely as little as possible on UI based things.Open an issue on github and publish somewhere your tests. I think we can cooperate on having good tests that work with the config. Thanks.
I would suggest using Drush
I would suggest using Drush to run tests instead of doing it through the web interface. You're going to run into the same problem where some tests will fail because they're expecting to be run in the context of a web server, but at least the failures will be more stable - you won't have failures after tweaking something in your Nginx config. Also, running just a subset of tests - say, just the test suite(s) for your own custom modules - is much easier and faster.
That being said, if you have the time and willpower, an even better idea is to figure out why the test is failing, and if you're sure it's something in Drupal core that's at fault, submit a patch, then ask for others in the non-Apache groups (Nginx, IIS, etc) to try the patch and post their results in the issue.
The Tokyo Drupal Guy!