Use composer to configure the test environment [#2010042]

Why can't we support the simple workflow

cd drush
composer install --dev
php vendor/phpunit/phpunit/phpunit.php

We need composer: drush dl composer

We need to run composer: drush composer install --dev

Open Issues

We need to run phpunit from the project directory
- move phpunit.xml.dist to drush root
- configure it differently

We need a database
- Why not set sqlite as default?
Original

Puzzled by #1841324-8: Requiring php 5.3.5 for Drush is premature

If the test suite passes, I'm OK

so I checked the project https://drupal.org/project/drush/testing-status page which has 'way back' testing result so that's not how drush does it.

Next to discover the drush project page tells about Travis integration which is cool but does it on commit.

Why not add the following to the project page:

To test your patch locally install the drush composer
Next run drush composer install --dev

It needs some more commands as I failed to get the tests running :(

Attached patch is a first shot which obviously needs work.

Comment	File	Size	Author
#26	drush-running-tests-locally-2010042-26.patch	2.47 KB	helmo
#22	drush-running-tests-locally-2010042-diff-17-22.txt	1.55 KB	clemens.tolboom
#22	drush-running-tests-locally-2010042-22.patch	2.52 KB	clemens.tolboom
#17	drush-running-tests-locally-2010042-17.patch	2.23 KB	clemens.tolboom
#6	drush-running-tests-locally-2010042-6.patch	2.34 KB	clemens.tolboom
#3	drush-running-tests-locally-2010042-3.patch	2.23 KB	clemens.tolboom
	drush-running-tests-locally.patch	407 bytes	clemens.tolboom

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 3 June 2013 at 13:44

Assigned:

Unassigned

» clemens.tolboom

From IRC joestewart wrote

don't know if it helps but there is a readme in the tests directory - http://drupalcode.org/project/drush.git/blob/refs/heads/8.x-6.x:/tests/R...

That helps :) (doh)

Comment #3

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 3 June 2013 at 14:48

File	Size
drush-running-tests-locally-2010042-3.patch	2.23 KB

It all comes down to rtfm. Attached patch makes the pain go away a little.

But I hope we get the information on the project page more clearly.

An improvement would be to default to a sqlite database.

I normally do

cd project
composer install --dev
php vendor/phpunit/phpunit/phpunit.php

That works because the phpunit.xml.dist is in the project root and configured to point to the tests/ directory.

Comment #4

moshe weitzman CreditAttribution: moshe weitzman commented 3 June 2013 at 14:52

Category:	task	» support
Status:	Needs review	» Fixed

Please pay close attention to the tests/README.txt. It mentions: 'From the /tests subdirectory, run `phpunit .`. Now you need this line: "Review the configuration settings in phpunit.xml.dist. If customization is needed, copy and rename to phpunit.xml and edit away."

I just committed a couple enhancements to the README so it is easier to find our test suite.

Comment #4.0

moshe weitzman CreditAttribution: moshe weitzman commented 3 June 2013 at 14:52

Issue summary:

View changes

Updated issue summary.

Comment #5

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 3 June 2013 at 14:56

Category:	support	» feature
Status:	Fixed	» Needs review

This is still a feature request then.

I added composer.json --dev switch which ease the burden to install anything.

Comment #6

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 4 June 2013 at 13:31

Title:	How to run tests locally?	» Use composer to configure the test environment
Component:	Miscellaneous	» Tests

File	Size
drush-running-tests-locally-2010042-6.patch	2.34 KB

Installing PHPUnit the old way is a pitb. Using composer is not.

Current patch sets version to the version from the README.txt: >=3.5

By using composer install --dev we get a newer version. It brings in a newer yaml v2.2.2 which is not good I guess as /lib contains v2.2.1
[edit]added v2.2.1[/edit]

Comment #7

moshe weitzman CreditAttribution: moshe weitzman commented 6 June 2013 at 14:32

Status:

Needs review

» Needs work

I'm not sure why we would add a new dependency on Drush Composer. Isn't composer enough? And if so, shouldn't composer based install be an additional install method. Ther eis also the PHAR option. Not sure how to proceed here. See http://phpunit.de/manual/current/en/installation.html#installation

Comment #8

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 6 June 2013 at 14:58

There is only a ease of use dependency on drush composer. Composer is good enough.

But the installation is now almost a no-brainer instead of a battle with pear, apt-get and the likes.

So I prefer the drush dl composer but maybe just add a link to http://getcomposer.org would do?

(or am I missing a point?)

Comment #9

moshe weitzman CreditAttribution: moshe weitzman commented 6 June 2013 at 17:35

The issue is, we already recommend that folks install drush via PEAR. maybe we should deemphasize pear completely and go with Composer for both drush and phpunit? I'll ask MarkS to chime in.

Comment #10

saltednut

she/her

English

Chicago

CreditAttribution: saltednut commented 6 June 2013 at 19:43

maybe we should deemphasize pear completely and go with Composer for both drush and phpunit?

+1 for this practice. K.I.S.S.

Comment #11

msonnabaum CreditAttribution: msonnabaum commented 6 June 2013 at 20:17

I don't think this is necessary. It's not difficult to install phpunit via pear.

Also, I strongly dislike encouraging the use of drush composer. Composer is already pretty simple to use, there's no reason we should hide it's native interface from users.

Comment #12

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 7 June 2013 at 07:53

I completely disagree with installing through PEAR is a no-brainer. I had it working on OS X 10.5/6/7 not on 10.8 and stopped trying. I have more PHP projects depending on different versions of phpunit or other 'alien' packages. Running composer install --dev works like a charm with those project.

With composer we can tell what exact versions we decide drush should use for runtime or development. With that option it doesn't matter anymore what my system wide version is of component xyz.

I even think we should move Yaml + Console Table from lib to vendor and make it properly registered through composer.json. That would be in line with Core 8 packaging Symfony and other components.

Note that this DEV stuff depends on http://phpunit.de/manual/current/en/installation.html

Support for Composer and PHP Archive (PHAR) was added in PHPUnit 3.7 (and is known to be stable since PHPUnit 3.7.5). Earlier releases of PHPUnit are not available through these distribution channels.

and

PHPUnit 3.7 requires PHP 5.3.3 (or later) but PHP 5.4.7 (or later) is highly recommended.

Keep in mind that when we make the on-boarding experience for Drush development easier it's a win-win. (I myself am running drush test now for the first time due to this patch)

Comment #13

helmo CreditAttribution: helmo commented 7 June 2013 at 09:25

I see composer as an improvement. Having it system wide would be 'nice', but complicates instructions. As the with the current README. It says

-On Linux/OSX:
----------
-
- sudo apt-get install php5-curl php-pear

Sure apt-get should be on any system ;) but the truth is... This is less OS dependant and does not require root privileges.

my 2 cents...

Comment #14

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 7 June 2013 at 11:00

XREFs
- #1316322: Add PSR-0 autoloader to drush
- #1792550: Facilitate installing via Composer.

Comment #15

greg.1.anderson CreditAttribution: greg.1.anderson commented 7 June 2013 at 16:48

I agree that composer is more straightforward than pear. I know how to install via pear, and update / fix problems with pear, but still, every now and then I have to check the docs do a little magic dance before the little pear pony will jump through its hoop. I suspect that composer install will reduce the aggregate fiddling that the community needs to do.

My vote would be to fix per #7.

Comment #16

msonnabaum CreditAttribution: msonnabaum commented 8 June 2013 at 03:06

To clarify, I mostly object to any docs that suggest using drush composer rather than just composer itself. If we want to just add it as a dev dependency, and tell people to run vendor/bin/phpunit, I'm fine with that.

Comment #17

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 13 June 2013 at 13:30

Status:

Needs work

» Needs review

File	Size
drush-running-tests-locally-2010042-17.patch	2.23 KB

I've rewritten the README from a novice perspective.

Comment #18

saltednut

she/her

English

Chicago

CreditAttribution: saltednut commented 13 June 2013 at 14:43

+++ b/tests/README.txtundefined
@@ -29,9 +35,40 @@ In order to speed up test runs, Unish (the drush testing class) caches built Dru
+the novice way
+
+- Download Drush composer:
+  $ drush dl composer
+- Automagically install phpunit:
+  $ drush composer install --dev
+
+the quick way
+
+- Follow the installation instruction from
+  - http://getcomposer.org/download
+- now run composer depending on your installation from the drush root directory
+  - php composer.phar install --dev

How about promoting some best practices here? Someone who is new will also likely be looking for quick answers - why would someone do something "the novice way" instead of "the quick way" and what's the difference? Finally, "the hard way" - as Mark pointed out, its not that hard and the next line it says "installing with PEAR is easiest"
I don't mean to be rude but if I came across this doc I'd be angry and confused.

Comment #19

greg.1.anderson CreditAttribution: greg.1.anderson commented 13 June 2013 at 17:44

I don't think we need to document three ways to install phpunit; if the getcomposer technique works cross-platform, let's just document that.

Comment #20

saltednut

she/her

English

Chicago

CreditAttribution: saltednut commented 13 June 2013 at 19:17

Status:	Needs review	» Needs work
Issue tags:		+Needs documentation

Comment #21

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 14 June 2013 at 11:26

Assigned:

clemens.tolboom

» Unassigned

Hmmm ... I missed #16

and tell people to run vendor/bin/phpunit, I'm fine with that.

which is in line with #19.

That means we can drop the hard way. Which is completely broken on my hand installed, then homebrew-ed broken env. So I like the composer way.

What I like about multiple ways is people interested in testing will probably try the novice way first. That would be a great 'on-boarding experience' I hope.

Regarding #18