Three releases (VS 2015 Update 3, Visual Studio “15” Preview 3, MSTest V2) featuring Test Platform components in as many months indicate a path best traced by starting from the present.

The Test Platform Presently, Visual Studio has an open and extensible test platform with tests being written using various test frameworks and run using a variety of adapters. The Test Platform, from its vantage, resolves the lifecycle of the test into a series of stages – two of which are writing and running the test – with the goal of providing extensibility at each stage.

The Test Lifecycle The below diagram illustrates the lifecycle:

And in broad terms, the stages can be described as follows:

• The Test Platform supports running tests written in various test frameworks using a pluggable model. Based on user-choice, the desired test framework and its corresponding adapter can be acquired as a vsix or as NuGet package as the case may be. Adapters can be written in terms of a public API exposed by the Test Platform – for e.g. here is a description of the Chutzpah adapter’s implementation.
• The next stage is to write the test. Based on the framework/adapter tuple, tests may be authored for Managed code, for native code, for JavaScript code, etc. When authored from within the Visual Studio IDE, then Project templates, wizards, IntelliSense and the rest of the code editing infrastructure comes into play here.
• All authored tests are made available for running. Optionally, various attributes of the tests may be used to select a subset. Selection can be done by test case name, by grouping them based on criteria like project/class/traits/outcome/duration, by applying a filter, etc. This ability to select tests is available from the Test Explorer, from the command line (vstest.console.exe), as well as from the VSTest task. Selection enables focusing on the set of tests to run.
• The system configuration to use to run the tests – the processor architecture (x86/x64) to use, the target .NET Framework to use, the set of data collectors to be in effect when the tests are run, etc.  – can be precisely set. Such configuration is set using the .runsettings file, and there are adapter-specific sections within this file (owned by the adapter writers, of course).
• Then comes the run stage where the selected tests are run as configured and using the appropriate adapter. This is the testrun – the most often repeated stage in the life cycle. Tests may be run using the Test Explorer, command line (vstest.console.exe), as well as from the VSTest task.
• Application-platform-specific debugging is supported to enable high-fidelity debugging for tests targeting the desktop, Store, UWP, and so on.
• Feedback from the testrun is analyzed to figure out the outcome of each test, the duration, and – if configured – the code coverage data, and data from any other data collectors that may have been active.
• The feedback is then reported for user-consumption. This is done on the Test Explorer if you are in the Visual Studio IDE or – if you are using the commandline – on stdout, as a .trx file, or published to TFS. Loggers, like adapters, can be plugged-in to the Test Platform to provide custom logging/reporting.

Efficiency as a Theme for features across the life cycle Efficient execution has been the pervading theme for the features we have implemented across the stages in this lifecycle – not restricted only to efficient “running” of the tests alone, but efficiency in executing across the entire lifecycle. After all, as a developer, one wants to get from conceptualizing the tests, all the way to the point where they are generating reports that can inform business decisions.

Next post – recap of the features We will continue this series in the next post, looking at the features we have implemented and delivered in the Visual Studio 2015 cycle that enable such efficiency.

Stay tuned.