Once you've got some code written, it's time to debug your application.   Fortunately you've got two way of running your code: emulator or physical device.   Though the emulator has its drawbacks, it's just fine for many scenarios.   Use it as much as you can since it's faster to deploy and run.   Deploying on the phone gives you full access to hardware including sensors and touch, along with the appropriate speed.   Now that the code is running on something, it's time to try the code.

Breakpoints are your friend!   Anywhere that it makes sense you should set breakpoints, examine threads and variables, use tracepoints to display values/messages, and pause execution when you need to.   The debugger has some challenges though.   If your application uses the camera or photo library, or pretty much any task/chooser, the application will be tombstoned for the duration.   This means that the debugger can't help you anymore!   Hit F5 when it returns to your code so you get back into the debugging.

Another thing to realize is that anything photo-/media-related won't work while connected to the computer via USB.   You won't get a message - it just returns from the chooser immediately.   If you need to take a photo or select a tune, keep this in mind or you'll pull your hair out.

You can tell if you're running under the emulator and/or debugging using API calls.   Use the Debugger.IsAttached call to see if it's debugging mode.   This can be handy to avoid task/chooser calls since you'll know they'll fail since you can only debug while connected.   To detect the emulator vs. the device, check the Microsoft.Devices.Environment.DeviceType for a value of Microsoft.Devices.DeviceType.Emulator.

For situations that I need to disconnect for testing, I find it helpful to resort to old-school MessageBox debugging.   You can also create a debugging ViewModel to pass data into, and show fields in a Popup control as needed.

The most difficulty that I have is with location.   You can fake location data with some extra work, but you can't simulate the actual complexities of the GPS sensor not getting a lock, getting a signal with a low accuracy, or just dropping the signal.   Similarly, network connections come and go, change bandwidth, and sometimes just don't seem to do anything.   Debug as much as you can in a controlled environment, but there's a huge variety of scenarios to cover that can only be properly handled by real-world testing.   Just be sure to have some backdoor data to examine so you can see what's happening out there.

Did I miss anything?   What else is helpful in the area of Windows Phone debugging?