Andrea, the testing framework is a Java project. We chose Java over PHP because we wanted to try Selenium 2 WebDriver and PHP is not officially supported by SeleniumHQ anymore, whereas Java is. The unofficial PHP language bindings had some limitations and the documentation wasn't great.
It's still early days but so far I have been working on object repositories from the default, vanilla Moodle install to be used in conjunction with the integration process. Hopefully the project will be available on GitHub today if all goes to plan. I've left Moodle acceptance tests in there as examples.
I have tried to refactor as much as possible to simplify things. My goal is to have the tests written in a manner that can be interpreted easily by someone who has limited programming knowlege (this may assist later with behavioural or test driven development). I haven't produced much documentation yet all I have Javadocs but I have not created a user guide yet.
I am interested in is any help with the following:
1) Writing the page objects.
2) Any further refactoring to simplify things further.
3) Finding out how well it works with non-vanilla Moodle sites and any feedback/recommendations/improvements on this.
4) Any developer wizzardry to make the tool more intelligent and handle unexpected events.
I have allowed for some internationalization with onscreen text based locators and test data being stored in properties files so they can be easily customized to suit the site they are being used on. I'm trying to make the page objects handle Moodle with Javascript turn on and off and also handle other unpredictable events. The strategy for locators is to try the following:
1) locate by unique, static id.
If not possible e.g. id='submit' can't really be used because it is present on many submit buttons:
2) locate by unique, static css selector (selectors that can be displayed on the web page such as the value selector must be passed from properties file).
If not possible e.g. more than one object sharing CSS Selectors on the same page:
3) locate by onscreen text using xpath e.g. //a[contains(.,'some text')] to locate a link with 'some text' passed from properties files, or from tests using parameters (and test data properties) if the link was created by the test itself.
Recently I refactored some of my more complicated methods into utility methods in a bid to reduce the number of lines of code in the page objects.
It's still very early days and any improvements and contributions would be very much appreciated.