General developer forum

Everyone--How do you test your plugins?

 
Picture of Kimber Warden
Everyone--How do you test your plugins?
 

I'm curious about the best ways to test plugins in development, especially those that are triggered by a scheduled task in cron.

When I'm writing code, I include print screen output at strategic points to give me information about how my code is working. Then I run cron through the browser interface and watch the output on screen. It works fine but is agonizingly slow. I can only set my scheduled task to run every minute at the most, which means that every time I tweak the code, I have to wait up to a minute to test it. And if I don't run cron at precisely the top of the minute, I miss the whole process and have to wait another minute to try again.

There has to be a better way, but I don't know what it is. I would love it if folks shared their testing methods so I can learn to test more efficiently. Thanks for helping me figure this out!

One bit of information: I do have access to my server's command line, but I do not have super user permissions, so I'm limited on what I can do there. For example, I tried to run cron by entering "php /path/to/cron.php" and received "Fatal error: $CFG->dataroot is not writable, admin has to fix directory permissions! Exiting."

 
Average of ratings: -
Davo
Re: Everyone--How do you test your plugins?
Core developersParticularly helpful MoodlersPlugin developers

Well, step 1 would be to install PHP on your local computer and develop and test there, rather than on a live server. That way, you can run cron on the command line, rather that having limited access to a separate server.

The next step would be to use admin/tool/task/cli/schedule_task.php (off the top of my head, so there may be a typo in there) to run your scheduled task directly, rather than waiting for its turn in the cron.php script (schedule_task.php has params --list to show all scheduled tasks and --execute=<taskname> to run a single task).

Finally, I'd advise setting up xdebug + a suitable IDE (I use PHPStorm, but others work as well), then you can stick a breakpoint in your code, trigger the scheduled task and step through the code a line at a time and see exactly what is happening (including the full contents of every variable).


 
Average of ratings: Useful (3)
Picture of Richard Oelmann
Re: Everyone--How do you test your plugins?
Core developersParticularly helpful MoodlersPlugin developersTesters

What version of Moodle are you using Kimber?

I've written quite a few of these kind of things recently and on the newer versions of Moodle, in the Scheduled Tasks page, each one has a 'Run Now' option. Like you I write all kinds of echos, print_r and other comments into the code for just this purpose, then I can run it and look at just the output of that task. That also avoids the need to run cron directly from the command line, or allowing permission to run it from the browser.

Once I've run it I can leave that browser window open, make any changes/fixes, then just click refresh to run the task again.

Works quite well for me smile

I then reduce the comments and echos etc to something more meaningful rather than error trapping and reporting once its ready for production.

 
Average of ratings: Useful (2)
Picture of Kimber Warden
Re: Everyone--How do you test your plugins?
 

I'm using 3.0 right now, but planning to upgrade this summer. It's good to know that a "run now" has been included on the scheduled tasks page of the newer versions!

 
Average of ratings: -
Picture of Mark Johnson
Re: Everyone--How do you test your plugins?
Core developersParticularly helpful MoodlersPlugin developers

Further to Richard and Davo's suggestions, once you have a local development environment set up, you could also consider writing some automated tests with PHPUnit.

This allows you to set up some test data that looks like the data your code will actually use, execute the scheduled task for your plugin, then examine the data programmatically to make sure your code did what you were expecting.  The big advantage to doing it this way is that when you change your code in the future (or upgrade the underlying Moodle installation), you can make sure you don't accidentally break existing behaviour.

 
Average of ratings: Useful (3)