GSoC 2015 – Moorsp Plugin for Moodle – Update 8

The past week saw me reconfiguring my complete Moodle instance to get Behat testing working again, and the beginning of writing Behat tests for the Moorsp Plagiarism Plugin. I began writing tests for the following functionality:

  1. Enable/Disable Moorsp plugin – Completed
  2. Enable/Disable Moorsp submissions for assign – Completed
  3. Enable/Disable Moorsp submissions for workshop – Completed
  4. Enable/Disable Moorsp submissions for forum – Completed
  5. Show student plagiarism disclosure when submitting – Completed
  6. Show plagiarism level (whether plagiarised or not) on grading screen
  7. Show/hide plagiarism info from student

I will continue to write Behat and PHPUnit tests for the plugin next week.


Running PHP applications in Apache Tomcat 7

Apache Tomcat 7 is a popular server for running Java applications – but say you have a unique instance where you want to run both PHP and Java applications on Tomcat but don’t want to run two separate servers (i.e. Apache HTTPD + Tomcat) to achieve it?


For this we’re going to use the PHP – Java Bridge for Tomcat, which is a handy little package that will sort out PHP execution on top of Tomcat.

The first step is to download the Javabridge template from this link at SourceForge. This will give you a WAR file that you can directly drop in to your Tomcat server’s webapps folder.

For Windows users, the next step is to download PHP and extract it somewhere:



For Linux users, just install php5 using apt-get, yum, or your preferred package management tool.

Next step is to add PHP to the PATH variable. Append the path to your PHP folder to the end of your respective PATH variable.

Next, drop the JavaBridgeTemplate61.war file in to your Tomcat server’s webapps folder and start Tomcat.

When you navigate to your server’s Java Bridge folder (this is http://localhost:8080/JavaBridgeTemplate61/ by default), you’ll be able to see the Java Bridge’s index page:

Javabridge welcome page


If you go to javabridge/test.php, you’ll be able to see the output from the phpinfo() function:



If you open up test.php in the JavaBridgeTemplate folder in your Tomcat’s webapp folder, you can edit some of the code:





Now you can deploy any PHP application within the JavaBridgeTemplate folder and rename the folder to whatever you want. You can add many folders like this for different PHP applications.

Note that the JavaBridge runs PHP as CGI. If you want to enable/disable specific PHP extensions you can simply enable them as you would do normally on your php.ini file.

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 6

Another week in GSoC 2015 has gone by, and I’ve been busy working on the Moorsp Plugin for Moodle.

My main task during the past week was to complete the functionality of the Moorsp plugin and to ensure that it checks for duplicate submissions by comparing the filehashes of uploaded files.

Moodle takes two forms of submissions for assignments, forums and workshops; file uploads and online text. To store online text in the plagiarism_moorsp_files table, I hash the contents of the submission and store it with content_hashvalue as the filename.

The get_links() function is called, which in turn calls the get_file_results() function which carries out the actual comparison of files in the context of Moorsp. This will add a checked image to each submission as follows (green check mark for files that are not plagiarised, red warning sign for those that have been plagiarised).

Plagiarised submission


The next step is to start writing Unit Tests and Behat tests to provide test coverage for the Moorsp plugin.

GSoC 2015 – Moorsp Plugin for Moodle – Update 5

Another week of GSoC 2015 passes by and I have managed to make some advances in my project of building the Moorsp plugin for Moodle.

During the past week, I migrated the plugin to the new Events API described here, and in the process added an Observer class to watch for Moodle Plagiarism events.

The Observer in Moorsp is currently configured to handle events related to assessable_uploaded, with more event support to be built in during the coming week.

Dan, my mentor for the project, has suggested that I move the observer to a /classes folder within the plugin to enable autoloading.

During the past week I found the debugging framework in Moodle to be extremely helpful in finding out the values of various params without having to use an external debugger.

The $observers array in Moorsp currently takes the form of;


$observers = array (
 * Event observers
 'eventname' => '\assignsubmission_file\event\assessable_uploaded',
 'callback' => 'plugin_moorsp_observer::assignsubmission_file_uploaded',
 'includefile' => '/plagiarism/moorsp/observer.php'
 'eventname' => '\mod_workshop\event\assessable_uploaded',
 'callback' => 'plugin_moorsp_observer::moorsp_observer_content_uploaded'
 'eventname' => '\mod_forum\event\assessable_uploaded',
 'callback' => 'plugin_moorsp_observer::moorsp_observer_content_uploaded'
 'eventname' => '\assignsubmission_onlinetext\event\assessable_uploaded',
 'callback' => 'plugin_moorsp_observer::moorsp_observer_content_uploaded'

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

GSoC 2015 – Moorsp Plugin for Moodle – Update 4

The 4th week of GSoC 2015 has gone by and I’ve been continuing to work on the Moorsp plugin for Moodle.

During the past week, I completed the following tasks:

  • Fixed issues in Moorsp showing the student disclosure message during a submission
  • Continued to work on the file_uploaded and files_done event functions in Moorsp. The files_uploaded event is fired whenever a student uploads a file as part of a submission. The files_done event is fired when students have sent in their submissions for grading. Both of these methods need to check whether the file included in the event data has been added to the moorsp_files table, and add it if it has not.
  • Wrote code to store content hashes of files in the moorsp_files table. This is an important part of the initial version of Moorsp as the goal is to check the filehashes of two files together as a very basic plagiarism check. Since Moorsp is more of a plugin developed to execute tests on the plagiarism framework, it is not necessary to have more complicated plagiarism checks.

GSoC 2015 – Moorsp Plugin for Moodle – Update 3

The first week of coding for GSoC 2015 proved to be a pretty busy one for me as I continued work on integrating Moorsp in to its supported modules. I completed the following tasks during the past week:

  • Added an install.xml file to the plugin which creates the initial database tables as Moorsp is being installed.
  • Completed the settings form which is displayed alongside the settings for each module that uses Moorsp – for example, if mod_assign uses Moorsp, editing settings on an assignment will give a form to edit Moorsp settings for that assignment.
  • Completed saving module-specific settings to the Moorsp config table.
Moorsp now inserts a settings form in to modules that use it
Moorsp now inserts a settings form in to modules that use it
  • Worked on my first implementation of a plagiarism event within Moorsp: the moorsp_event_files_done() function maps to the files_done() event in the plagiarism framework and enables files to be added to the database for later processing by Moorsp.

That’s it for this week – my fork of Moorsp can be here for further reference.

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!

GSoC 2015 – Moorsp Plagiarism Plugin for Moodle

For the 3rd time in my life, I have been selected as a Google Summer of Code student (after mentoring for the past 2 years, I might add) to work on a project for Moodle.

Moodle is one of the most prominent and widely-used Free and Open Source Learning Management Systems in the world today, and has a widespread developer community. I had particular interest in Moodle because it is the LMS used by most Sri Lankan universities to manage their degree programmes, which speaks volumes for the robustness and feature-rich nature of Moodle. Moodle development is done through PHP and MySQL.

My project involves the development of Moorsp; a skeleton plagiarism plugin for Moodle which integrates with the plagiarism framework within the system. The purpose of this plugin is to provide an effective testing mechanism for the plagiarism framework, as all current plagiarism plugins connect to commercial 3rd party APIs and testing them is not possible without a paid account. Moorsp will integrate with the plagiarism framework, implementing all its hooks and events, thereby providing a platform for acceptance tests (Behat) to be written for the plagiarism framework itself. This would provide a free plugin that could be utilized for regression runs during continuous integration on Moodle.

GSoC is in the Community Bonding phase at the moment. I have been engaging with the community on their forums and have also provided some Behat feature files for QA tests that were not yet automated.

I’m pretty excited, and looking forward to a great summer with this awesome organization!

Moodle Logo


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.

 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<button_string>(?:[^"]|\\")*)"$/
 * @throws ElementNotFoundException Thrown by behat_base::find
 * @param string $button
public function press_button($button) {

    // Ensures the button is present.
    $buttonnode = $this->find_button($button);

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.