Apple doesn't make it easy to test your code when you start getting close to the framework classes. I've found UIApplication particularly difficult due to its singleton nature, and the fact that the framework creates the instance for you during setup. Solutions to problems like this usually depend on how you're testing; for example, do you have a valid UIApplication object in your tests? If you're using OCUnit then [UIApplication sharedApplication] may itself return nil, unless you've set up your test target to run in your application bundle (I've never managed to get this to work, honestly).
One option is to simply not test this. Most of the time your interactions with the main window are relatively simple, and tests of this code are testing the UIKit framework as much as your own code. This is a stylistic decision that depends on how you've structured your code, how comfortable you are leaving this small area untested (or, more appropriately, un-test-automated), and how difficult it will be to write the tests.
If you have code that relates to the UIWindow object that you decide you do need to test, I would suggest you encapsulate the functionality in a way that you can then control under test. You could do this by creating a subclass of UIApplication for your app which returns the UIWindow object from a custom method. Use this method in your code, rather than accessing the window property directly, and in your tests override this method to return whatever you like.