Best practices for debugging mail scripts?

[karstenvan]

Just curious what practices people find most effective for debugging mail scripts (ie. in Workflow notifications).

Beyond the basic template.print inclusions, once you start adding script logic, gr queries, fields from various places, etc... it is easy to run into bugs.   However, unlike other areas of the system where there are debugging tools, it is hard to identify mail script issues as all you get when you execute a buggy notification is a blank message body... and thats only after you test run the workflow.

What tips/tricks do people have for making this debugging process easier?

[Ken83]

I tend to add several gs.log() statements, probably excessively, throughout my code during the initial creation process. That way I can see every step of the way what values i'm getting and makes it easier to pin point where the script breaks. In your situation, the mail script is still a script so somewhere in that code, I would add several gs.logs because behind that scenes, that script is what will create your notification. If something goes wrong in the script, you'll know why you got a blank message. To take that a step further, you can also utilize the additional parameter accepted by gs.log() to make it easier to find when you review the logs. (i.e gs.log("Log text goes here","This is where it came from");

[Brad Tilton]

Logging definitely helps as Kenneth suggests.

I also usually use the Scripts - Background module to test my notification scripts before putting them in the notification itself.

[simonw]

Moving anything complex into a script include has been a big help for us, we actually use script includes to build the entire e-mail body at present so its very easy to test the output in background scripts.  

[Kalaiarasan Pus]

I use display business rules always to debug them. Just paste the code and if there are any template.print statements replace it with gs.addInfoMessage. Helps a lot in quick testing and debugging.