Drush integration

Hi andreiashu

First of all, thanks for the cool patch! It looks like you know what you are doing so I added you as a maintainer of the drunit and commited the patch to CVS. I think it's a great starting point for moving drunit forward!

I have several thoughts about the patch, but got stuck on trying to make it run the testDrunitClassExtends correctly. In the process I changed an include to use the PHPUnit version 3.5.10 way of bootstrapping. I also needed to set error_reporting to 0 in my php.ini file due to some double imports, will look into that.

Are very busy the next couple of weeks but then it should ease out. Bare with me!
Cheers

Rune

Ok some first thoughts.

== drunit_drush_phpunit3.5.patch ==
Looks good!

== Comment#6 ==
Used pear and everything was fine after I updated pear to 1.9.1 using pear :)

== drunit_drush_integration_1.patch ==
1) Naming of test folder, "tests" or "drunit".
Thinks it is cleaner and more explicit to not mix drunit tests and Drupal Simpletests. That would also make most of the code in drunit_test_get_all_classes() go away.

2) Drush integration.
All three of "drunit-list", "drunit-run" and "drunit-run-all" is easily accomplished by using the phpunit command with simple switches. I'm constantly using a number of switches like "--stop-on-error", "--tap", "--wait" and "--coverage-html" and it seems messy (for not to mention boring:) to port all switches of PHPunit to the drush-run* scripts.

3) DrunitTestListener.
Never used one of those, whats the advantages to the standard PHPUnit run?

4) Moving settings to main settings.php
Thats a lot better than having a separate settings file! Think the "_conf" postfixes can be omitted. There is going to be some funkiness regarding precedence if we want to keep the option to run with xml configuration files too.

5) support for *AndAjaxWait function calls
Of __call magic thats not too bad, and looks usable!

6) The selenium* methods
Should be made available through a class var instead, with the code in its own class, see 9? Extremely useful!

6a) seleniumCreateNode
Think the method definition could be something like
seleniumCreateNode($nodeType, $data, $settings)

It also looks too specific.

7) The drupal* methods
Should be made available through a class var instead, with the code in its own class, see 9? Extremely useful!

8) The random* methods
Should be moved to a DrunitRandom class?

9) selenium*, drupal*
This represents two ways of manipulating the site. I've also worked on simply posting and getting by changing the $_POST, $_SET, $_SESSION, etc. global variables and then inside an output buffer including the index.php file. Works quite well too and is a lot faster than running selenium. What's a good category name for these three types? And what would be a good way to provide access to these in the test classes?

Ok thats it for now
Cheers!!!

Rune

EDIT: Removed notions of using DI.

Testing email notificatons.

1) Yes I mean to simply use "drunit" instead of "tests". "tests" is already "occupied" by Drupal Simpletest. I thinks it is ok to mix PHPUnit and Selenium tests in the "drunit" folder.

2a+4) http://www.phpunit.de/manual/3.5/en/phpunit-book.html#organizing-tests. You did it "Using the TestSuite Class" and I did it "Composing a Test Suite Using XML Configuration". I don't know whats best, needs experimentation and writing about pros and cons.

2b) I don't think we should use Drush just for its bootstrapping features as it is pretty simple to do standalone.

3) Nuke it, things not used should die! :)

8) Don't like the notion of an "Utils" class, they often end up being a messy dump of all the code you don't now where to place. Thats why I mentioned the "Random" class.

9) Even without multiple inheritance (or traits:) we could easily have something like:

<?php
class MyTestClass extends Drunit_XXXX {
  function testTest() {
    // As a class attribute.
    $this->selenium->open(SOME_URL);
    $this->drupal->post(...);
    // Or nested deeper. 
    $this->site->selenium->open(SOME_URL);
    $this->site->drupal->post(...);
  }
}
?>

Take care!
Rune

N.B.: Oh and by the way. At least where I'm at, if you google for "phpunit" the Drunit page is second :)

1) "drunit" it is then.

2a+4)
Yes, shy of doing a system() call to the phpunit executable :) OK, lets ditch the XML config hell, who uses XML anyway :)

2b) I don't mind the manual includes and am not the biggest fan of adding Drush as a dependency but I guess it is the de facto standard of running Drupal from the command line. Am a bit worried that it will give E_NOTICE's though. Lets try Drush out!?

8) Good plan about not making a mess, agreed!

9) "$this->selenium->doSomething" is agreed upon!

> I think I'll be able to provide a new patch for this sometime next week.
Sweet. Am deep inside a Django project a.t.m. so am mostly in Python-land, but will try to find some time!

Cheers!
Rune

Subscribe... looks like some of this stuff has been committed according to the git logs?

Yes the patch "drunit_drush_integration_1.patch" is in the repo. Can't wait....git is coming!!!