Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.2
    • Fix Version/s: 2.3
    • Component/s: Unit tests
    • Labels:
    • Rank:
      38500

      Description

      Basic support for phpunit testing:

      • bootstart file - must be used in "-c" parameter or in xml config file - see phpunit.xml.dist
      • initialisation of separate database and dataroot - see config-dist.php, use admin/tool/phpunit/cgi/util.php
      • basic_testcase for tests that do not modify database - it detects changes in CFG, USER and database (resets them if necessary)
      • documentation is in lib/phpunit/readme.md
      1. cvs.php
        5 kB
        Tim Hunt
      2. git.php
        3 kB
        Tim Hunt
      3. phpunit.class.php
        3 kB
        Tim Hunt

        Issue Links

          Activity

          Show
          Petr Škoda added a comment - work in progress branch: https://github.com/skodak/moodle/compare/master...wip_MDL-31857_m23_phpunit
          Hide
          Dan Poltawski added a comment -

          From the looks of the read me it looks like you are not investigating adding a simple test wrapper layer? Any reason its not possible - I did a few hours playing ages ago and it seemed possible for basic stuff: https://gist.github.com/3447938b23629b65f461

          Show
          Dan Poltawski added a comment - From the looks of the read me it looks like you are not investigating adding a simple test wrapper layer? Any reason its not possible - I did a few hours playing ages ago and it seemed possible for basic stuff: https://gist.github.com/3447938b23629b65f461
          Hide
          Petr Škoda added a comment -

          Grrrr! I was looking for the assertSame() thing yesterday and ended up implementing it myself - I have learned a lot by reading the PHPUnit source code. I did not think much yet about BC and emulations, I had hard times just trying to make it work and thinking about potential performance improvements.

          Potential problems I found (I will make a complete list in the readme.md)

          • assertTrue() casts to bool in SimpleTest automatically, expects bool parameter in PHPUnit
          Show
          Petr Škoda added a comment - Grrrr! I was looking for the assertSame() thing yesterday and ended up implementing it myself - I have learned a lot by reading the PHPUnit source code. I did not think much yet about BC and emulations, I had hard times just trying to make it work and thinking about potential performance improvements. Potential problems I found (I will make a complete list in the readme.md) assertTrue() casts to bool in SimpleTest automatically, expects bool parameter in PHPUnit
          Hide
          Petr Škoda added a comment -

          I think that the SimpleTest emulation class would be great for documentation purposes - devs would see immediately what are the differences in assertXXXX().

          Show
          Petr Škoda added a comment - I think that the SimpleTest emulation class would be great for documentation purposes - devs would see immediately what are the differences in assertXXXX().
          Hide
          Petr Škoda added a comment -

          wip branch updated - it looks like that only some 20% of tests run with the emulation class

          Show
          Petr Škoda added a comment - wip branch updated - it looks like that only some 20% of tests run with the emulation class
          Hide
          Dan Poltawski added a comment -

          I assume most of the other tests are more complicated DB related things? Still it might be a win for third party stuff.

          Show
          Dan Poltawski added a comment - I assume most of the other tests are more complicated DB related things? Still it might be a win for third party stuff.
          Hide
          Petr Škoda added a comment -

          Either database (we do not need to create tables manually) or some advanced $this->assert() with extra extra class, also there is a problem with missing global $CFG before includes above the test class.

          Show
          Petr Škoda added a comment - Either database (we do not need to create tables manually) or some advanced $this->assert() with extra extra class, also there is a problem with missing global $CFG before includes above the test class.
          Hide
          Petr Škoda added a comment - - edited

          I have shuffled the files a bit after discussing this with Tim, the description is now at https://github.com/skodak/moodle/tree/w12_MDL-31857_m23_phpunit/lib/phpunit

          ciao

          Show
          Petr Škoda added a comment - - edited I have shuffled the files a bit after discussing this with Tim, the description is now at https://github.com/skodak/moodle/tree/w12_MDL-31857_m23_phpunit/lib/phpunit ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          TIA and ciao

          Show
          Eloy Lafuente (stronk7) added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
          Hide
          Tim Hunt added a comment -

          1. Why tests folder, and not phpunit (which was proposed earlier)

          2. I thought that DB prefix had to be <= 4 chars because of table-name length limits. $CFG->phpunit_prefix = 'phpu_'; is 5 chars.

          3. We talked about making a simple web-runner script, that executed the PHPunit command-line, captured the output, and displayed it in <pre> tags. We need this at the OU. We develop on a server where we don't have CLI access. I understand you may not have implemented that in the first version, but please at least add this to the TODO list in https://github.com/skodak/moodle/blob/w12_MDL-31857_m23_phpunit/lib/phpunit/readme.md

          4. Everywhere else in Moodle that we rely on PEAR libraries, we include the libraries in lib/pear. Why are we not doing that with the PHPunit libraries? The code in lib/phpunit/lib.php and lib/phpunit/bootstrap.php makes me think there is no problem with including the libraries in lib/pear.

          5. How about making $CFG->phpunit_dataroot default to $CFG->dataroot . '/temp/phpunit'?

          6. I think some of your class names could be improved. For example a class called phpunit_manager with comment "Collection of utility methods." makes me think that either the class name, or the comment, is wrong. If the comment is right, why not call it phpunit_utils?

          Similarly the class names basic_testcase and advanced_testcase are really unhelpful. The only place these names will be used is in lines like class ... extends basic_testcase, so there is no problem if the class names are longer, and it is a big help if the class names make it very clear what these classes do.

          7. Surely all these classes should have names starting phpunit_... or core_phpunit_... (except for the ones that need to be backwards compatible like UnitTestCase).

          8. Do we need to mention the PHPUNITTEST constant in so many places in core code? It seems that many of them could be eliminated if we set CLI_SCRIPT when running unit tests, but I realise that might affect how the code we want to test works.

          9. You can configure PHPunit to use any convention you like for test file names. You don't need to use Test.php.

          10. Who peer reviewed this, why is a major change like this submitted for integration without peer-review?

          Show
          Tim Hunt added a comment - 1. Why tests folder, and not phpunit (which was proposed earlier) 2. I thought that DB prefix had to be <= 4 chars because of table-name length limits. $CFG->phpunit_prefix = 'phpu_'; is 5 chars. 3. We talked about making a simple web-runner script, that executed the PHPunit command-line, captured the output, and displayed it in <pre> tags. We need this at the OU. We develop on a server where we don't have CLI access. I understand you may not have implemented that in the first version, but please at least add this to the TODO list in https://github.com/skodak/moodle/blob/w12_MDL-31857_m23_phpunit/lib/phpunit/readme.md 4. Everywhere else in Moodle that we rely on PEAR libraries, we include the libraries in lib/pear. Why are we not doing that with the PHPunit libraries? The code in lib/phpunit/lib.php and lib/phpunit/bootstrap.php makes me think there is no problem with including the libraries in lib/pear. 5. How about making $CFG->phpunit_dataroot default to $CFG->dataroot . '/temp/phpunit'? 6. I think some of your class names could be improved. For example a class called phpunit_manager with comment "Collection of utility methods." makes me think that either the class name, or the comment, is wrong. If the comment is right, why not call it phpunit_utils? Similarly the class names basic_testcase and advanced_testcase are really unhelpful. The only place these names will be used is in lines like class ... extends basic_testcase, so there is no problem if the class names are longer, and it is a big help if the class names make it very clear what these classes do. 7. Surely all these classes should have names starting phpunit_... or core_phpunit_... (except for the ones that need to be backwards compatible like UnitTestCase). 8. Do we need to mention the PHPUNITTEST constant in so many places in core code? It seems that many of them could be eliminated if we set CLI_SCRIPT when running unit tests, but I realise that might affect how the code we want to test works. 9. You can configure PHPunit to use any convention you like for test file names. You don't need to use Test.php. 10. Who peer reviewed this, why is a major change like this submitted for integration without peer-review?
          Hide
          Tim Hunt added a comment -

          Here is some crude code I wrote that does run PHPunit as part of the web interface of another application. It worked for me.

          Show
          Tim Hunt added a comment - Here is some crude code I wrote that does run PHPunit as part of the web interface of another application. It worked for me.
          Hide
          Tim Hunt added a comment -

          And attached is a crude example of a script that runs a command-line program and displays the output from a web-accessible script.

          Show
          Tim Hunt added a comment - And attached is a crude example of a script that runs a command-line program and displays the output from a web-accessible script.
          Hide
          Tim Hunt added a comment -

          This might be a better example to uses. It does something a bit more complex, so it can do progressive output from a slow-running command-line script (CVS)

          Show
          Tim Hunt added a comment - This might be a better example to uses. It does something a bit more complex, so it can do progressive output from a slow-running command-line script (CVS)
          Hide
          Petr Škoda added a comment -

          1/ 'phpunit' collides with admin/tool/phpunit, 'unittests' collides with current simpeltest UI, 'test' could collide with modules, the only reasonable name I found is 'tests' which seems matching to current special purpose db, pix, lang directories. Also in future we may need to add more test files - we could create subdirectories in /tests/ which would prevent more reserved directory names.

          2/ table prefix length is database dependant - the limit is 2 chars for Oracle only and non-empty for all databases, longer prefixes are valid for MySQL and PostreSQL; the DML driver tells you when the prefix is not supported or it fails during install.

          3/ web runner UIs can be done later in admin/tool/phpunit - I am not going to work on it now, the TODOs reflect what I am going to do before 2.3 release; feel free to work on that

          4/ phpunit is not PHP library - it is command line tool, PHPUnit is not required to run Moodle, author of PHPUnit encourages to always use PEAR (I can not find the exact page now where he said that), the size of all required and recommended libs is relatively big and it needs some extra PHP extensions we do not require in moodle - I try really hard to get rid of as much PEAR as possible from Moodle distribution, adding non-essential libs would soon lead to redistribution of all PEAR libs; sorry I strongly disagree here

          5/ dataroot should be imo completely separate - it uses different owner and permissions; standard temp may be purged at any time; I want to separate production sites as much as possible

          6/

          • phpunit_manager - I agree, it evolved over time and the name lost its meaning - changing
          • basic_testcase - it does not do much, no idea how to call it
          • advanced_testcase - I do not know what is it going to do, pretty much everything else basic does not, what name woudl you propose?

          7/ the testcase are distinct from stock PHPUnit classes, theoretically they would not even have to use phpunit, I do not think the "phpunit_" prefix is actually helpful, but I agree we need something that can not collide with the rest of moodle and libraries

          8/ PHPUNIT constant will be in more places over time, in any case it can be changed later because the tests do not use it directly, only the bootstrap process and core

          9/ I did not manage to allow custom file name pattern when executing phpunit on one specific directory (and believe me I tries very hard). I do not see any major problem in that, I never liked our camel_case rules. If we find a way to support "*test.php" we can change it before release - changing case in future will not be possible (it creates very nasty problems in case-insensitive filesystems).

          10/ I discussed all details with Eloy. Apart from the naming rules there is not much to discuss I think. The code is self-contained and even if it gets integrated on Monday it can be changed easily before release (still a few months away) and even then it will be semi-experimental. Martin wants to get this integrated asap, it was already delayed 2 months thanks to my illness and now by one week thanks to releasing, sorry.

          SUMMARY:
          --------

          • I will rename phpunit_manager to phpunit_util
          • I will add forgotten functional DB tests to readme.md TODO
          • we need to decide basic_testcase naming - does not seem right, but I have no idea how to improve it (I do not like phpunit_ prefix)
          • I will remove advanced_testcase for now until we know more about it
          • somebody needs to double check if it is not possible to have *test.php file name pattern when running phpunit with directory parameter (by reading the PHPUnit source code)

          Thanks very much for all your valuable feedback, you have highlighted the same area I was myself not sure about. If you agree with my arguments above I would add more FAQs to the readme file, if we do not agree I guess it would be safer to delay the integration by one week.

          To integrators: please do not integrate before regular meeting on Monday

          Show
          Petr Škoda added a comment - 1/ 'phpunit' collides with admin/tool/phpunit, 'unittests' collides with current simpeltest UI, 'test' could collide with modules, the only reasonable name I found is 'tests' which seems matching to current special purpose db, pix, lang directories. Also in future we may need to add more test files - we could create subdirectories in /tests/ which would prevent more reserved directory names. 2/ table prefix length is database dependant - the limit is 2 chars for Oracle only and non-empty for all databases, longer prefixes are valid for MySQL and PostreSQL; the DML driver tells you when the prefix is not supported or it fails during install. 3/ web runner UIs can be done later in admin/tool/phpunit - I am not going to work on it now, the TODOs reflect what I am going to do before 2.3 release; feel free to work on that 4/ phpunit is not PHP library - it is command line tool, PHPUnit is not required to run Moodle, author of PHPUnit encourages to always use PEAR (I can not find the exact page now where he said that), the size of all required and recommended libs is relatively big and it needs some extra PHP extensions we do not require in moodle - I try really hard to get rid of as much PEAR as possible from Moodle distribution, adding non-essential libs would soon lead to redistribution of all PEAR libs; sorry I strongly disagree here 5/ dataroot should be imo completely separate - it uses different owner and permissions; standard temp may be purged at any time; I want to separate production sites as much as possible 6/ phpunit_manager - I agree, it evolved over time and the name lost its meaning - changing basic_testcase - it does not do much, no idea how to call it advanced_testcase - I do not know what is it going to do, pretty much everything else basic does not, what name woudl you propose? 7/ the testcase are distinct from stock PHPUnit classes, theoretically they would not even have to use phpunit, I do not think the "phpunit_" prefix is actually helpful, but I agree we need something that can not collide with the rest of moodle and libraries 8/ PHPUNIT constant will be in more places over time, in any case it can be changed later because the tests do not use it directly, only the bootstrap process and core 9/ I did not manage to allow custom file name pattern when executing phpunit on one specific directory (and believe me I tries very hard). I do not see any major problem in that, I never liked our camel_case rules. If we find a way to support "*test.php" we can change it before release - changing case in future will not be possible (it creates very nasty problems in case-insensitive filesystems). 10/ I discussed all details with Eloy. Apart from the naming rules there is not much to discuss I think. The code is self-contained and even if it gets integrated on Monday it can be changed easily before release (still a few months away) and even then it will be semi-experimental. Martin wants to get this integrated asap, it was already delayed 2 months thanks to my illness and now by one week thanks to releasing, sorry. SUMMARY: -------- I will rename phpunit_manager to phpunit_util I will add forgotten functional DB tests to readme.md TODO we need to decide basic_testcase naming - does not seem right, but I have no idea how to improve it (I do not like phpunit_ prefix) I will remove advanced_testcase for now until we know more about it somebody needs to double check if it is not possible to have *test.php file name pattern when running phpunit with directory parameter (by reading the PHPUnit source code) Thanks very much for all your valuable feedback, you have highlighted the same area I was myself not sure about. If you agree with my arguments above I would add more FAQs to the readme file, if we do not agree I guess it would be safer to delay the integration by one week. To integrators: please do not integrate before regular meeting on Monday
          Hide
          Petr Škoda added a comment -

          repo updated

          Show
          Petr Škoda added a comment - repo updated
          Hide
          Petr Škoda added a comment -

          the db prefix length for everything except Oracle is at least 34 chars - see http://docs.moodle.org/dev/XMLDB_key_and_index_naming

          Show
          Petr Škoda added a comment - the db prefix length for everything except Oracle is at least 34 chars - see http://docs.moodle.org/dev/XMLDB_key_and_index_naming
          Hide
          Sam Hemelryk added a comment -

          I will be looking at this tomorrow (sorry time got sucked up on E_STRICT review)

          Show
          Sam Hemelryk added a comment - I will be looking at this tomorrow (sorry time got sucked up on E_STRICT review)
          Hide
          Petr Škoda added a comment -

          YAY! Sam found a way to allow "*_test.php", I have updated the branch, thanks!!

          Show
          Petr Škoda added a comment - YAY! Sam found a way to allow "*_test.php", I have updated the branch, thanks!!
          Hide
          Sam Hemelryk added a comment -

          Hoorah! This has been integrated now thanks Petr!
          As discussed I did make an additional commit after merging these changes just to fix typo's and phpdocs.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hoorah! This has been integrated now thanks Petr! As discussed I did make an additional commit after merging these changes just to fix typo's and phpdocs. Cheers Sam
          Hide
          Petr Škoda added a comment -

          oh, and I thought I fixed most of them, thanks a lot!!

          Show
          Petr Škoda added a comment - oh, and I thought I fixed most of them, thanks a lot!!
          Hide
          Sam Hemelryk added a comment -

          Haha you did, there were several I remembered from the other day that I found you had fixed. Only a couple of typo's were left, the only one worth mentioning was that plugin_suite_start and plugin_suite_end tags that I fixed up (were plugin_suit_start|end).
          The PHPdoc fixes were really just correcting things as per the new standards, the changes I made there were really only filling in a couple of gaps and ensuring @package and @category were consistent.
          Once more thanks Petr!

          Show
          Sam Hemelryk added a comment - Haha you did, there were several I remembered from the other day that I found you had fixed. Only a couple of typo's were left, the only one worth mentioning was that plugin_suite_start and plugin_suite_end tags that I fixed up (were plugin_suit_start|end). The PHPdoc fixes were really just correcting things as per the new standards, the changes I made there were really only filling in a couple of gaps and ensuring @package and @category were consistent. Once more thanks Petr!
          Hide
          Tim Barker added a comment -

          I have in the past and also today, had issues installing PHPUnit from pear on Ubuntu using the instructions on PHPUnit website. It would be nice if we could include the following instructions in the readme:
          sudo pear channel-discover pear.phpunit.de
          sudo pear channel-discover components.ez.no
          sudo pear channel-discover pear.symfony-project.com
          sudo pear upgrade
          sudo pear upgrade phpunit/PHPUnit
          The default aptitude package from Ubuntu causes fatal errors in our tests.

          Show
          Tim Barker added a comment - I have in the past and also today, had issues installing PHPUnit from pear on Ubuntu using the instructions on PHPUnit website. It would be nice if we could include the following instructions in the readme: sudo pear channel-discover pear.phpunit.de sudo pear channel-discover components.ez.no sudo pear channel-discover pear.symfony-project.com sudo pear upgrade sudo pear upgrade phpunit/PHPUnit The default aptitude package from Ubuntu causes fatal errors in our tests.
          Hide
          Tim Barker added a comment -

          Got the framework installed and ran 1 test, all from 1 dir and all tests. Apart from my notes about the install instructions everything is cool.

          Show
          Tim Barker added a comment - Got the framework installed and ran 1 test, all from 1 dir and all tests. Apart from my notes about the install instructions everything is cool.
          Hide
          Sam Hemelryk added a comment -

          Congratulations are in order, you've made it, or at least your code has!
          It's now part of Moodle and both the git and cvs repositories have been updated.

          This issue is being marked as fixed and closed.

          Thank you.

          Show
          Sam Hemelryk added a comment - Congratulations are in order, you've made it, or at least your code has! It's now part of Moodle and both the git and cvs repositories have been updated. This issue is being marked as fixed and closed. Thank you.
          Hide
          Matt Gibson added a comment -

          This is a great move IMO - thanks for all the work! Can we have support for Selenium test cases built in to the test interface? We're looking at using PHPUnit_Extensions_Selenium2TestCase here, so a way to specify connection details etc for the WebDriver API would be amazing.

          More details here: http://www.phpunit.de/manual/3.7/en/selenium.html

          Show
          Matt Gibson added a comment - This is a great move IMO - thanks for all the work! Can we have support for Selenium test cases built in to the test interface? We're looking at using PHPUnit_Extensions_Selenium2TestCase here, so a way to specify connection details etc for the WebDriver API would be amazing. More details here: http://www.phpunit.de/manual/3.7/en/selenium.html
          Hide
          Petr Škoda added a comment -

          Yes, selenium support would be nice to have, anybody wants to implement it?

          Show
          Petr Škoda added a comment - Yes, selenium support would be nice to have, anybody wants to implement it?
          Hide
          Tim Barker added a comment - - edited

          It would be fantastic if we can do something with WebDriver and PHP, it would be awesome to integrate into Moodle, however:

          At HQ I am working on Selenium already. There are a few things to consider though before implementing anything. I started using Selenium 1 (RC) as part of a trial but I couldn't get it working in Grid mode and there were a few organizational concerns because it had been tried before.

          The purpose of the work that I am doing is to add more testing to the integration process and automate functional regression testing for major releases.

          We are currently using Selenium 2 (WebDriver) which, although still fairly new, has a number of advantages over RC. WebDriver supposedly supports Ajax better and has a significantly lighter API. It is very incomplete but I have created an object repository, utility methods some of the Moodle acceptance tests. Currently in Java because it's fully supported .

          The Grid setup with WebDriver makes parallel testing for performance and load testing very easy too.

          I tried the PHP bindings for WebDriver as part of my assessment of Selenium and desperately wanted them to work. I'm interested in the PHPUnit extensions but the "WebDriver API.." is "..(partially implemented)", which implies using Selenium RC with all of it's limitations. I suspect that it is an implementation of WebDriver backed with Selenium 1 RC. I tried this and found it quite flaky; once again it's not fully implemented and some functionality of Selenium is lost.

          If we want WebDriver to work fully with PHP we may have to consider extending it further ourselves. SeleniumHQ have no plans to do anything with PHP in the future. The Selenium community contributions to PHP and WebDriver are very poor, incomplete and don't utilize the full power of WebDriver. Implementing this will be a lot of work.

          Matt: I would like to know what you have tried with WebDriver so far, what have you done yourself in PHP for WebDriver. I may be able to help and I might have something that you can use from my own work.

          Show
          Tim Barker added a comment - - edited It would be fantastic if we can do something with WebDriver and PHP, it would be awesome to integrate into Moodle, however: At HQ I am working on Selenium already. There are a few things to consider though before implementing anything. I started using Selenium 1 (RC) as part of a trial but I couldn't get it working in Grid mode and there were a few organizational concerns because it had been tried before. The purpose of the work that I am doing is to add more testing to the integration process and automate functional regression testing for major releases. We are currently using Selenium 2 (WebDriver) which, although still fairly new, has a number of advantages over RC. WebDriver supposedly supports Ajax better and has a significantly lighter API. It is very incomplete but I have created an object repository, utility methods some of the Moodle acceptance tests. Currently in Java because it's fully supported . The Grid setup with WebDriver makes parallel testing for performance and load testing very easy too. I tried the PHP bindings for WebDriver as part of my assessment of Selenium and desperately wanted them to work. I'm interested in the PHPUnit extensions but the "WebDriver API.." is "..(partially implemented)", which implies using Selenium RC with all of it's limitations. I suspect that it is an implementation of WebDriver backed with Selenium 1 RC. I tried this and found it quite flaky; once again it's not fully implemented and some functionality of Selenium is lost. If we want WebDriver to work fully with PHP we may have to consider extending it further ourselves. SeleniumHQ have no plans to do anything with PHP in the future. The Selenium community contributions to PHP and WebDriver are very poor, incomplete and don't utilize the full power of WebDriver. Implementing this will be a lot of work. Matt: I would like to know what you have tried with WebDriver so far, what have you done yourself in PHP for WebDriver. I may be able to help and I might have something that you can use from my own work.
          Hide
          Matt Gibson added a comment -

          Tim B: I'm just having a look at all this now - I've not done much work on it at all, but I'm keen to get started. I'm evaluating the service from SauceLabs (https://saucelabs.com), who seem to be putting some effort into making all this work smoothly, so perhaps we can piggy back on their efforts. They have extended Selenium IDE into SauceBuilder (http://saucelabs.com/builder) which exports the recorded tests as PHP in one click (with or without the code to run it with their ondemand service), as a class that extends PHPUnit_Extensions_SeleniumTestCase. The other option is to use ondemand, which has it's own set of PHP classes here: https://github.com/saucelabs/phpunit-selenium-sauceondemand which I'm learning from.

          Our main drive is to get quickly set up with an automated testing framework as soon as possible, so I'm skimming over webdriver in favour of saucelabs at the moment, but will feed back what I find out here. We may be able to commit some time to extending webdriver PHP support in future.

          Show
          Matt Gibson added a comment - Tim B: I'm just having a look at all this now - I've not done much work on it at all, but I'm keen to get started. I'm evaluating the service from SauceLabs ( https://saucelabs.com ), who seem to be putting some effort into making all this work smoothly, so perhaps we can piggy back on their efforts. They have extended Selenium IDE into SauceBuilder ( http://saucelabs.com/builder ) which exports the recorded tests as PHP in one click (with or without the code to run it with their ondemand service), as a class that extends PHPUnit_Extensions_SeleniumTestCase. The other option is to use ondemand, which has it's own set of PHP classes here: https://github.com/saucelabs/phpunit-selenium-sauceondemand which I'm learning from. Our main drive is to get quickly set up with an automated testing framework as soon as possible, so I'm skimming over webdriver in favour of saucelabs at the moment, but will feed back what I find out here. We may be able to commit some time to extending webdriver PHP support in future.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: