I don't test »against« or »with« themes. Just with some other plugins that might conflict (but I normally leave that open until something happens - you'll never figure out all edge cases).
At least, you're intercepting/extending/altering stuff via filters. So why test against themes, when you're modifying core functions?
If you're intercepting
the_content filter for example, then why would you take a look at themes? If they jump in at priority
99999999, then you're anyway too late and the chance that they change it in another release is that high, that you wouldn't be able to follow anyway.
Imagine, that you'd check every filter - with for example the
all-hook - jump in and move your priorities around until there's no chance that you'd miss it, then you'd bring the system down to its knees. It is possible. But it doesn't work in real live.
WordPress, as well as PHP got a bunch of error handling stuff on board. This means, that everything that fails, will be output - as long as it's turned on. Do that in any case in your local copy... and abort in live code!
My best advice is to simply build yourself a really neat and easy debugging environment. When I write my classes, I normally add debug output to any containing method. This ways I can see what happens and when it happens.
Why am I doing this?
Simple: Errors will occur at some step. So normally you would start adding points where to stop, look at the output/returned data and then step forward until you catch the error. I'm just making my life easier with a simple switch, that allows me to output this stepped data: One tab in my meta box in the shutdown hook at a time. If the result isn't what I expected, then error/wrong piece of code happens right before that.
This allows me to jump in, whenever something fails. It also allows me to reproduce error prown installations and see what happens without any additional effort.
The other thing I often use it
var_dump( $GLOBALS['wp_filter'][ current_filter() ]; to see what else is attached to the hook, where I'm currently jumping in.
Never ever output errors in live installations
When you look at how I did it with the »Dynamic image resize« plugin - a plugin that is a better TimThumb (replacement) - then you'll see how I avoid output for
- Users that don't have the right privileges
- Owners that forgot to turn debug stuff off by accident
As you can read from the comment above: I assume that no one has turned on DEBUG stuff while using a caching plugin. In this case: No one will be able to help.
At least it's Open Source. And if there's really some caveman who does it... then it's not your fault if things fail. You can't catch any edge case. :)
A last word
Why don't I test for missing hooks, etc.?
There are »Theme development standards« that every valid theme should follow. If they don't, then they're simply not on my radar. Imagine, that I'd give a note with for e.g.
_doing_it_wrong() for every case something fails. This would bloat my code to approx. 10 times of the original size - without catching everything that could be written wrong.
Now imagine, that someone got a really crappy theme and I'd throw 10 messages at her/him with one plugin. What would happen if we'd all care about that? 1.000 messages?