When we made the move from using Custom Labels to store app settings to using the new hierarchical Custom Settings to do so, our testMethods started failing due to null pointer references.  From what I've seen, when you go to install a package with Custom Settings definitions via AppExchange, even if you set defaults for it when creating the settings, they are not passed to the target org.  The target org seems to be required to hit the Manage button and accect/create/modify the default settings for the org wide defaults before they can be used.  This is a problem since these won't exist during an AppExchange install, and can't be managed until the install would be done, at which point it's already failed out our testMethods that call code referencing expected default values.

What is the proper way to use Custom Settings and still ensure that code coverage is achieved, and that they can be packaged for the AppExchange without defaulting to being null?