Make the test run context available for the adapter, to allow a choice between IDE vs Console runs

[pvlakshm]

This came in as feedback during the .NET Core Tools PGI meeting on 17 Jan 2017. Requires more drill down.

[clairernovotny]

The scenario here is that some users may want the to only run tests on the CLI while hiding them in the GUI. If the adapter knew about the caller (some kind of "user agent" like thing -- CLI/GUI/etc), then we could add a config option to hide tests from a certain caller.

[AbhitejJohn]

@onovotny : Can you expand on that use-case please? When would someone want a test to not appear in a GUI runner and only run from CLI? Wouldn't that cause test gaps in the inner loop for folks using the gui runner only for their development?

[clairernovotny]

The scenario is that some people have cases where they want to use the test explorer for integration style tests with javascript frameworks or other frameworks. But they don't want their unit tests to show up in the UI.

@bradwilson has gotten this request many times in the past.

[codito]

Proposal:
Add RunConfiguration.DesignMode boolean in runsettings.

If a test discovery/run is triggered by an Editor/IDE, DesignMode will be true.
In case of a run from command line, DesignMode will be false.

For backward compatibility, adapters may keep default value of DesignMode as true; and read the value only if it is provided by runsettings.

[AbhitejJohn]

@codito : That looks pretty consistent with the workflow we already have with DisableAppDomain and the other global settings. 👍
One other interesting use-case that helps performance in console scenarios is that adapters can now skip finding DIA source information which isn't of much help in a non-GUI workflow.