When modifying a system without adequate tests, I found it helps to include debugger breakpoints in my manual testing checklist:
For each change I make, I add a breakpoint after the modified line, and won’t remove it until the interpreter has passed through it exercising the logic to my satisfaction. Before committing the changes I can pull up the list of breakpoints to make sure I’ve hit them all.
This is probably most valuable when I’ve made a lot of changes at once, or if temporary delusion is making me think I don’t need to test everything.
Caveat 1: I suppose, if there’s any parallel operations, you should also test everything with the breakpoints gone, lest the code relies on losing a race condition.
Caveat 2: In no way is this a substitute for automated tests!
Today I had one of those bugs that starts out looking simple and keeps going deeper and deeper. Video service Kaltura has a plugin for Moodle, that just stopped working one day (no changes on the server).
- It’s throwing an exception because an expected element isn’t in the page.
- Oh, the element’s supposed to be delivered by XHR from the plugin.
- But the plugin’s code is generating correct markup…
- Why is Moodle’s function to serialize an array into a JS function call returning
null for that markup?
json_encode is converting the markup string to null?
json_encode is choking on invalid UTF-8.
- Because the markup has a right single quotation encoded in Windows-1252 :(
- And that string is coming from the Kaltura API.
So over 2 years ago someone named a video player Jim’s Test Player and over the weekend Kaltura’s API started returning that single quote in Windows-1252. We removed the quote from the name and the problem disappeared.
xdebug-211-xampp-osx.tgz contains a freshly compiled xdebug 2.1.1 module for XAMPP OSX, using this tutorial as a guide. The archive contains step-by-step install instructions w/ bash commands.
Happy debugging with fewer bugs.
Zend Framework has functionality to send messages to the Firebug console (via Firefox’s FirePHP addon), but if you’re not using the ZF front controller, the API is a bit of a pain. Besides your instance of Zend_Log, you must keep track of a few additional objects just to manually flush the headers after all your logging calls. Since I knew the old FirePHP class didn’t need this follow-up step, I figured I could just flush the headers after each send.
The result is FireLog. On the FireLog instance, calls to methods like log(), info(), warn(), etc. are proxied to an internal Zend_Log instance, while the methods send(), group(), and groupEnd() are proxied to the static methods on Zend_Wildfire_Plugin_FirePhp. In both cases the headers are set immediately using some simple ZF subclassing.