You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previous versions of TestDriven.Net included support for executing tests inside the Visual Studio process using 'Test With > In-Proc'. The DTE object could be passed to the test method like this.
Because the tests were executed inside a new app domain, this only really worked well for pure COM objects (like DTE). Objects that interoped with .NET code would have trouble crossing the app domain barrier into the default app domain where Visual Studio's .NET code base based.
I've added a new test runner that's currently called 'Ghost', but will probably replace the 'In-Proc' test runner. This runner executes code inside the default app domain, which makes calling Visual Studio objects that use .NET possible (as well as pure COM).
As well as allowing the DTE object to be passed in, any number of .NET services or MEF exports can also be passed.
For service objects, the service type will be inferred from the interface name (using naming conventions and a few special cases). Please let me know if there's any I've missed!
// Test the SVsExtensionManager servicevoidExtensionManager(IVsExtensionManagerem){foreach(var ex in em.GetEnabledExtensions()){
Console.WriteLine(ex.Header.Name);}}
When passing in MEF exports, the [Import] attribute is optional but [ImportMany] is required when passing multiple exports.
// Test a MEF importvoidPeekBroker([Import]IPeekBrokerpeekBroker){
Console.WriteLine(peekBroker);}
// Test many MEF importsvoidFindAll([ImportMany] EditorOptionDefinition[]eods){foreach(var eod in eods){
Console.WriteLine($"{eod}: {eod.ValueType}");}}
// MEF imports with metadata is also supportedvoidMarginProvider([ImportMany]Lazy<IWpfTextViewMarginProvider,IDictionary<string,object>>[]margins){foreach(var margin in margins){
Console.WriteLine(margin.Value);foreach(var kv in margin.Metadata){
Console.WriteLine($"{kv.Key}: {kv.Value}");}}}
If code needs to be executed on the Main thread, you can use an async method with SwitchToMainThreadAsync:
async Task FindNavigationItems(IServiceProvidersp){await ThreadHelper.JoinableTaskFactory.SwitchToMainThreadAsync();// code than requires the main thread}
I'm planning to make the following possible as an alternative (useful for a few services that must be retrieved on the Main thread):
[STAThread]voidRunOnMainThread(IVsRequireMainThreadrmt){// code than requires the main thread}
Let me know what you think and if you find any issues. 😄
The text was updated successfully, but these errors were encountered:
jcansdale
changed the title
Add support for spelunking Visual Studio services and MEF exports
Add support for spelunking Visual Studio services and MEF exports 'Test With > In-Proc (VS SDK)'
Jun 20, 2017
This functionality is now in Test Driven.Net 4.0-alpha as 'Test With > In-Proc (VS SDK)'
http://testdriven.net/download.aspx
Previous versions of TestDriven.Net included support for executing tests inside the Visual Studio process using 'Test With > In-Proc'. The
DTE
object could be passed to the test method like this.Because the tests were executed inside a new app domain, this only really worked well for pure COM objects (like DTE). Objects that interoped with .NET code would have trouble crossing the app domain barrier into the default app domain where Visual Studio's .NET code base based.
I've added a new test runner that's currently called 'Ghost', but will probably replace the 'In-Proc' test runner. This runner executes code inside the default app domain, which makes calling Visual Studio objects that use .NET possible (as well as pure COM).
As well as allowing the
DTE
object to be passed in, any number of .NET services or MEF exports can also be passed.For service objects, the service type will be inferred from the interface name (using naming conventions and a few special cases). Please let me know if there's any I've missed!
When passing in MEF exports, the
[Import]
attribute is optional but[ImportMany]
is required when passing multiple exports.If code needs to be executed on the Main thread, you can use an
async
method withSwitchToMainThreadAsync
:I'm planning to make the following possible as an alternative (useful for a few services that must be retrieved on the Main thread):
Let me know what you think and if you find any issues. 😄
The text was updated successfully, but these errors were encountered: