I have created my own simple wrapper around the BetterLog library, which provides some synaptic sugar and adds the function name to the beginning of each trace line, something I find helpful. BetterLog allows you to easily send the trace to a separate sheet which is very useful if you’ve got handlers running in different execution contexts.

Optimising the Script

It’s mainly service calls that slow down your code (more on that here), so along with the debug trace you are already using take a look in View>Execution transcript in the script editor to see any service calls that are unnecessarily inside loops, etc.

Error Handling

The overriding principle here is to make a distinction between operational and programmer errors in the code; keep programmer errors specifics away from the user (hopefully these will all have been dealt with during development) and cleanly deal and back out from the operational errors – things caused by the outside world like user input mistakes, external resources not being available, etc. This article is more to do with developing JavaScript for Node but it’s a great article on error-handling generally.

So I make sure any calls from within event handlers (simple or installable triggers, things like a file opening, form submission, etc.) are inside a try/catch so all errors thrown can be tidily logged and re-thrown in development, and either handled or reported to the user in production.

Testing

I have tried out a few of the testing frameworks libraries available for GAS, but decided to roll my own around the underscoreGS library [link TBD]. I found QUnit for GAS too cumbersome and I’d never get around to updating it and GSUnit was replicating a lot of the functionality I’d already included with underscoreGS. So I’ve got a bit more pragmatic and create simple unit tests functions in each module if they need them and they aren’t going to be easy to test as a user; things like lower level utility functions. These individual module test functions are all called from a master test function which I’ll link to a debug menu in the sheet or doc. The rest of the testing is done manually. My scripts haven’t yet got complicated enough to justify a completely simulated GAS environment for fully-automated testing. Although you can always develop your standalone scripts locally in eclipse, and stub-out or create emulated Google Services – but I’ve not tried that yet (I’m sure I’d read about someone doing this but couldn’t find the link).

Debug Menus

I find a dedicated debug menu in the sheet or doc can be useful to avoid having to keep going into the script editor to run functions during development.

Google APIs

There are limits to the Google App functionality that is exposed via the built-in GAS Services, however more can be accessed via the Google APIs they provide for all types of web apps to use. Here’s the Drive API for example. These are a bit trickier to use as you are poking around within JSON responses, and having to carry out authorisation but the extra power can be worth it some times – and they usually operate faster.

There is a utility called GasGit which you can use to upload scripts to Github, however it is a bit awkward to set up. Or you can just develop locally and use this Node utility to sync your files to Github and the load into the online script editor for running, but things will get messy if you start making changes in the script editor as well!