General developer forum

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).

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

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

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.