Want suggestions on remote testing of a driver and a user app to exercise it.

Sorry, but in lots of searching and browsing, I’ve not found any material on the practical problem of testing and debugging a driver on a remote target. I know a few of you have admonished me to use two computers for testing purposes, and I’ve found an old laptop at home and set it up (not quite seamlessly) to be a target computer.
But with all the documentation, tutorials and samples, I don’t see anything about exercising the driver once I’ve written and built it.
For example, I’ve downloaded and built the Echo WDF sample program in Visual Studio. It builds two alternative versions of a driver and an app that opens a file to one or the other of those. But I can’t run the app because it can’t find the driver, which is because there are no instructions about how to install the driver from the INF file. This is just on my local host computer.
I can manually copy my own driver over to the target computer and add it to the service manager registry stuff. I have my own app to exercise my driver, and I can copy that over to the target and run it on the target.
But what I really want to do is run two debuggers, one with windbg for the target kernel, and the other for the test app. And I want to be able to step through source code and variables, etc., just like I would do if running the test app locally.
I don’t want to debug the test app on the target using a debugger on the target, because the target doesn’t have the source code. So I see two other possibilities.

  1. Have a user mode windbg session on the target to launch the test app but be a server for a windbg client on the host. I haven’t succeeded so far in getting this to work.
  2. Run the test app on the host but somehow open a File which connects to the driver on the target. Maybe some fancy file name which involves the name of the target computer with the device name or symbolic link on the target.

I know you regular contributors (and I do appreciate you all) spend your working lives testing drivers that you write, and so you must certainly have worked out methods of doing this testing seamlessly.
So I invite (beg?) you to comment here about how you have managed this task. Thanks.