GSoC 2015 – Moorsp Plugin for Moodle – Update 10

The 10th week of my GSoC project for Moodle passed with me writing more Behat tests for the Moorsp plugin, completing the Behat test writing phase of development.

During writing tests I found some interesting bugs that were present in the code of Moorsp, most notable being that in onlinetext submission in the assign plugin, the content to be evaluated for plagiarism was being returned with <div class=”no-overflow”> tags around them, causing the filehashes to be mismatched and those text submissions not to be evaluated. I managed to build a workaround for this by hashing the contents with the offending tags included for onlinetext submissions.

Behat tests are running smoothly, with the main Behat tests implemented here.

Here is a sample of the final Behat test, show_teacher_plagiarism_status.feature, in action:

 

Behat tests in action

GSoC 2015 – Moorsp Plugin for Moodle – Update 7

During the past week, I’ve been busy working on testing the Moorsp plugin – through Unit Tests and Behat tests. I set up the PHPUnit environment for my Moodle instance and got it up and running. I also wrote most of the unit tests needed to test the class functions in the plugin, and had an interesting discussion on the Moodle forum whether form building functions should be tested on PHPUnit or Behat.

I also ran in to a slight problem running Behat tests after running PHPUnit, I posted a question on the forum and hope someone will be able to clarify that for me.

The current tests can be found here, and I will be adding to them continuously.

That’s it for this week!

GSoC 2015 – Moorsp Plugin for Moodle – Update 2

The 2nd week of GSoC and the final week of the Community Bonding period has rolled past, and I have been busy engaging with the Moodle community over the past couple of weeks.

As I explained to my mentor Dan, I see actually developing code as a great way to engage with the Moodle community as, in that case, I would be working on the Moodle Tracker and this enables me to interact with many members of the Moodle community through the peer review and integration testing processes.

As I had experience in writing automated Behat features beforehand, I thought the best contribution I could make would be to automate some of the top priority QA tests using Behat. So I worked on automating a couple of tests, MDL-50110 and MDL-50261. The first one was promptly accepted and integrated, while the 2nd it turned out, had already been automated. However, I got the chance to interact with the cool and calm dev community of Moodle who didn’t get frustrated by my repeated mistakes.

I also took some time to clean up the code of a Behat test I had been working on previously, MDL-43731, which is an interesting case as it required me to provide fixes on the Moodle 2.7 and 2.8 stable branches as well. This was a very interesting test to work on as I got input from over 8 members of the community who brought in different ideas on how to best automate the test. It was a very rewarding experience as I was able to understand the best practices involved with writing a Behat feature for Moodle.

While this was going on, I was working with my mentor Dan on getting started on developing the Moorsp plugin. My changes are currently going in to the dev branch on my fork of the Moorsp repo. As some initial work, I made some modifications to the Moorsp settings form so that it can be enabled for modules that support the Plagiarism framework. Dan was able to help me out with some snippets of code that would make use of the framework properly. I also had a lot of help from another commercial plagiarism plugin that Dan has developed; Urkund.

 

Moorsp Settings Page

That’s it from me for this week. See you soon!

Behat testing PHP applications with Moodle as an example

The Behat testing framework  advocates the relatively-new concept of Behavior-Driven Development (BDD)/Acceptance-Test Driven Development (ATDD), where human-readable tests are written for highly user-oriented tasks by the developers themselves. This automates the User Acceptance Testing (UAT) process to a certain degree as the tests themselves are not written in highly-technical terminology and follow front-end testing paradigms. Essentially, the idea is that you define a test on how your application should work from the front-end, and then develop that feature from there. Behat works on PHP 5.3 and upwards.

Moodle is a Free and Open Source Learning Management Tool with an active community from all around the world. Moodle is also a good example for extensive use of Behat to test its features. (I should note that Sahana makes use of the Robot framework for ATDD as well)

I thought of covering some of the basics in the Behat framework using examples from how Moodle does it. While Moodle’s implementation might be somewhat different from other projects that use Behat, the basics of each implementation should be reasonably similar.

The following is an example for a typical Behat test, which Behat calls a feature file.

@auth
 Feature: Login
   In order to login
   As a moodle user
   I need to be able to validate the username and password against moodle

   Scenario: Login as an existing user
     Given I am on "login/index.php"
     When I fill in "username" with "admin"
     And I fill in "password" with "admin"
     And I press "loginbtn"
     Then I should see "Moodle 101: Course Name"

   Scenario: Login as a non-existent user
     Given I am on "login/index.php"
     When I fill in "username" with "admin"
     And I fill in "password" with "admin"
     And I press "loginbtn"
     Then I should see "Moodle 101: Course Name"

Notice that the feature is written in Gherkin,  which is a feature language taken from Cucumber, the ATDD framework for Ruby on Rails. These Gherkin commands are tied in to a PHP function on the Behat framework, for example,

And I press "loginbtn"

ties in to;

/**
 * Presses button with specified id|name|title|alt|value.
 *
 * @When /^I press "(?P&lt;button_string&gt;(?:[^"]|\\")*)"$/
 * @throws ElementNotFoundException Thrown by behat_base::find
 * @param string $button
 */
public function press_button($button) {

    // Ensures the button is present.
    $buttonnode = $this-&gt;find_button($button);
    $buttonnode-&gt;press();
}

in behat_forms.php in the Behat framework. It is also possible to re-use these functions to write very specific test functions for your application. For example, Moodle contains an ‘Editing mode’ on the Courses module which allows course administrators and teachers to see edit links on various nodes within a course.  Moodle’s implementation of Behat provides

And I turn editing mode on

which translates to

/**
 * Turns editing mode on.
 * @Given /^I turn editing mode on$/
 */
 public function i_turn_editing_mode_on() {
   return new Given('I press "' . get_string('turneditingon') . '"');
 }

which is implemented in the behat_course.php custom class within Moodle’s course core module. Note that get_string($string) is a function specific to Moodle’s framework.

An interesting feature of Behat is its integration with Mink and Selenium Webdriver to execute the tests on UI itself. Once you run the tests, Selenium will open up a browser window and execute the steps described in each feature file sequentially, while you can watch it being executed.

The Moodle community provides a very comprehensive guide on how to get started with Behat on Moodle, so I will not reproduce that here. I will get on to describing more of the finer points of Behat testing later on.