So I've always been a big fan of using drush for debugging. You can see a little bit about it in Finding an exiting Page's Callback Function in Drupal. I find that some of the most annoying bits of testing what I'm doing comes when I'm dealing with Update Hooks. Check out what I do down below using drush to do my testing.
So check this out, drush eval is your friend. You can run ANY drupal function within a bootstrapped version of Drupal. This gives you lots of flexiblity in making one off scripts, tests, debugging, and of course, running update hooks. The trick here is that in any normal bootstrapped session, install files are not included. So you have to make sure to use module_load_install. Here is how you test a install hook.
drush eval "module_load_install('MY_MODULE')
MY_MODULE_update_7001();";
So this will run your update hook without setting your schema version on your module. This means you can run it over and over and over again.
Obviously this doesn't work with all update hooks. There are some that can be run without consequence over and over... while others you need to reinstall a sql file. I suggest that you do the following:
drush sql-dump > temp.sql
drush eval "module_load_install('MY_MODULE'); MY_MODULE_update_7001();"
Test
drush sql-drop -y
drush sqlc < temp.sql
This will ensure that you can continue to run your update script over and over... the downfall to writing update scripts that aren't aware the circumstances or are unable to actually run multiple times is it's not much different from running the following:
drush sql-dump > temp.sql
drush updatedb -y
Test
drush sql-drop -y
drush sqlc < temp.sql
Maybe a helpful hint or at the very least an outlook in the way I develop.