I've been working on a project that has a suite of applications that act as Add-Ins to various host applications. Testing a variety of scenarios can be slow if there is setup is involved, especially in a development environment. While you want to test going through as much of the your extensibility interface as possible, but you don't want to have to launch the host application, navigate through a few screens, and then launch just to test a small code or situational change. 
This is a great situation to use a VSTS Unit Test. Some might say "Duh," but for people who haven't thought about using unit tests for interactive testing, as opposed to the more traditional tests that assert success criteria and get executed after every build, I thought it might be helpful to walk through a simple example.
So I built a simple application, MyIntegrationApp. It has a Controller class that controls the flow of the app and exposes a Launch method that would be called by our fictional host application. In a real scenario, we may expose that method to be called via COM by an existing application.
Then I created a unit test project, MyUnitTests, that has test class, MyIntegrationAppTests. MyUnitTests also has a couple config files under a Configuration folder and subfolders that will be used during the tests. Finally, the unit test project references MyIntegrationApp. The figure to the right shows what the source tree looks like.
So let's look at the tests themselves. In my fictional scenario, the Controller class needs to load a configuration file, MyIntegrationApp.config. So I want to test three scenarios:
- There is a good config file in which case a success message will be shown
- There is a bad config file in which case an error message will be shown
- The config file is missing in which case a different error will be shown
So there are three test methods as seen in the next image. 
The first two methods use the DeploymentItem attribute to copy the specified config file. The third method doesn't copy the file. All three call a common private method that launches an instance of MyIntegrationApp. 
One tip to keep in mind is that you need to set the deployment items to Copy Always and build the unit test project so that they get copied to run folder.
The last thing to do is simply run the tests. To do this you open the Test View and right click on the test to run. Then select Debug selection as seen in the final image below.
So in summary, I think this can be an easy way to set up some tests that can help speed up the development and testing of Add-In applications. All the source code can be downloaded from here.
