An example of the problem is that when I happen to have $options['package-handler'] = 'git_drupalorg'; in my ~/.drush/drushrc.php, the unit tests are slow and they fail. That's because pm-download actually starts using git instead of tarballs. My personal drushrc has polluted the unit test environment. There are more examples of this pollution. If you look at the contextTest, it struggles mightily to not touch files that the current user is managing like the aforementioned drushrc.

  1. Do we come up with a way for drush to not look at user's home dir, server-wide directories, etc. when discovering config, alias, and commandfiles? Maybe check environment vars?
  2. Do we require unit tests to be run on "clean" VMs where the user and shared dirs are pristine?

Not too fond of my ideas :(. Hoping someone out there has a better one.

Comments

msonnabaum’s picture

I ran into this as well.

I think our only choice is ignoring any conf that we didn't write ourselves during the test run. We can still have tests that test the loading of the user's conf files, but for the rest of the command tests we should only load temporary confs that we created during setup.

greg.1.anderson’s picture

Take another look-see at my old bash scripts for producing diagrams for dgd7:

https://github.com/greg-1-anderson/drush-dgd7-scripts

In particular:

https://github.com/greg-1-anderson/drush-dgd7-scripts/blob/master/00-00-...

I just set the HOME environment variable somewhere else; no more pollution from $HOME/.drush/drushrc.php. It might also be a good idea to add a way to call drush_set_context('ETC_PREFIX', $somewhere_else); to take care of the stuff in /etc/drush.

moshe weitzman’s picture

Assigned: Unassigned » msonnabaum
Status: Active » Patch (to be ported)

Environment variables saved the day. Committed a fix for this as described by Greg in #2. Most of the changes were to the unit test suite. Drush changes were minor. See http://drupalcode.org/project/drush.git/commitdiff/0f61e3b

Safe to backport, IMO.

msonnabaum’s picture

Status: Patch (to be ported) » Fixed

Backported along with the tests to 4.

Status: Fixed » Closed (fixed)

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