{"id":25945,"date":"2016-11-29T20:27:27","date_gmt":"2016-11-30T03:27:27","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudioalm\/?p=25945"},"modified":"2019-02-14T15:56:00","modified_gmt":"2019-02-14T23:56:00","slug":"evolving-the-test-platform-part-3-net-core-convergence-and-cross-plat","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/devops\/evolving-the-test-platform-part-3-net-core-convergence-and-cross-plat\/","title":{"rendered":"Evolving the Visual Studio Test Platform – Part 3: .NET Core, convergence, and cross-plat"},"content":{"rendered":"

[This is the 3rd post in the series on evolving the Visual Studio Test Platform. You can read the earlier posts here:<\/em>\nEvolving the Visual Studio Test Platform \u2013 Part 2<\/a>,<\/em>\nEvolving the Visual Studio Test Platform \u2013 Part 1<\/a>]<\/em><\/p>\n

As .NET Core draws an ever-growing community of developers with existing assets and experiences, it is essential to support a consistent tools ecosystem<\/a>. Thus, the “alpha” release of the MSBuild-based .NET Core Tools<\/a> shipping with Visual Studio 2017 RC<\/a> introduces support for the MSBuild build system and the .csproj project format – both familiar and key components of the .NET tools ecosystem. The need for a consistent testing experience follows naturally. Thus, the .NET Core testing experience\/ecosystem is now converged with the Visual Studio Test Platform<\/a>.<\/p>\n

Concretely, this means the following:\n(1)<\/strong> Evolved test platform: vstest is now fully cross-plat (Windows\/Linux\/Mac). dotnet test<\/strong> now leverages this evolved\u00a0Visual Studio Test Platform.\n(2)<\/strong> Converged adapters: Adapter writers can maintain a converged adapter that can serve Visual Studio, the vstest.console.exe CLI and the dotnet CLI.\n(3)<\/strong> Converged user experience: the experience of using vstest.console.exe (the same options and capabilities) on the .NET Framework will be available on .NET Core as well.<\/p>\n

Let\u2019s see how \u2026<\/p>\n

Evolved test platform<\/h3>\n

The evolved vstest engine is presently named Microsoft.TestPlatform.V2<\/strong> and is packaged as a vsix extension. Launch Tools | Extensions and Update\u2026<\/code> and you will notice that this is already bundled with Visual Studio.<\/p>\n

\"5\"<\/a>\nC:Program Files (x86)Microsoft Visual Studio2017EnterpriseCommon7IDEExtensions<\/code> is the folder where extensions are installed.<\/p>\n

Converged Test Adapter for .NET Framework and .NET Core<\/h3>\n

When we first introduced MSTest V2 support there were 2 adapters – dotnet-test-mstest to target .NET Core<\/a>, and MSTest.TestAdapter to target the .NET Framework<\/a>. The dotnet-test-mstest adapter understands the project.json based project format. With .NET Core now supporting .csproj, that adapter is no longer required! Instead, the MSTest.TestAdapter can be used!<\/strong><\/p>\n

Launch Visual Studio 2017 RC, and create a Unit Test Project (.NET Core). This creates an MSTest V2 based solution targeting .NET Core. Now, look at the references.<\/p>\n

\"1\"<\/a><\/p>\n

The solution is self-contained – it refers the vstest engine, the MSTest V2 test framework, and the MSTest.TestAdapter to discover\/run such tests using the engine. And it is targeting .NET Core.<\/p>\n

\n

The same approach can be used by other test frameworks as well. For e.g., xUnit.net too has 2 adapters – dotnet-test-xunit to target .NET Core, and xunit.runner.visualstudio to target the .NET Framework, but with .NET Core now supporting .csproj, the dotnet-test-xunit is no longer required either. Instead, the xunit.runner.visualstudio adapter can be used. Here is a .NET Core unit test solution using the xUnit.net test framework:<\/p>\n

\"2\"<\/a><\/p>\n

The solution is self-contained – it refers the vstest engine, the xUnit.net test framework, and the xunit.runner.visualstudio test adapter to discover\/run such tests using the engine. This same adapter is used when targeting both the .NET Framework and .NET Core.<\/p>\n

[Note: the evolved test platform has the notion of a translation layer that enables interfacing with IDEs to perform common tasks like discover tests, run tests, get the results to display, etc.\u00a0This will be released soon on NuGet. In the meantime, we worked closely with the xUnit.net team to implement this support using early bits. We look forward to working with the community to extend this support.]<\/em><\/p>\n

Let\u2019s continue with this solution in our brief tour of the functionality.<\/p>\n<\/div>\n

Testing using the Visual Studio IDE<\/h3>\n

The below figure illustrates testing from within the Visual Studio IDE.<\/p>\n

\"34new\"<\/a><\/p>\n

This is same experience provided in the case of tests targeting the.NET Framework.<\/p>\n

Testing using vstest.console.exe<\/h3>\n

C:Program Files (x86)Microsoft Visual Studio2017EnterpriseCommon7IDEExtensions<\/code> is the folder where extensions are installed, remember? Locate vstest.console.exe<\/strong> under this folder.\nNavigate to the folder containing the xUnit.net test project, and use vstest.console.exe<\/strong> to run the tests as shown:\"6new\"<\/a>Notice that vstest.console.exe takes the DLL(s) as input \u2013 just like it does in the case of tests targeting the .NET Framework. Go ahead, try this out and see what other switches can be used!<\/p>\n

Testing using the .NET Core CLI<\/h3>\n

You can try these steps with latest dotnet-cli builds, since a critical bug fix couldn\u2019t make it to RC release.\nInstall the latest .NET Code SDK Preview build from here:\u00a0 https:\/\/github.com\/dotnet\/core\/tree\/master\/release-notes<\/a>. I downloaded it to the folder D:tempdotnet<\/code> on my machine.\nUse dotnet test<\/strong> to run the tests as shown:\"7new\"<\/a>\nThe command automatically picks up the .csproj file(s) and discovers and runs the appropriate tests using the referenced xunit.runner.visualstudio adapter.<\/p>\n

Testing using VSTS<\/h3>\n

To run the tests using VSTS, I setup a local build agent with Visual Studio 2017, and these same .NET Core SDK bits.\nHere is the build definition:\"8new\"<\/a><\/p>\n

Queue up a build and\u00a0you should see the report.\"9new\"<\/a><\/p>\n

Summary<\/h3>\n

The .NET Core testing experience\/ecosystem is now converged with the Visual Studio Test Platform. This is a huge benefit to everyone – same adapters, common invocation model, much broader feature set than CLI). As mentioned earlier, we will release the translation layer to NuGet soon, and look forward to working with you to get more adapters interfacing with the test platform.<\/p>\n

Stay tuned!<\/p>\n","protected":false},"excerpt":{"rendered":"

[This is the 3rd post in the series on evolving the Visual Studio Test Platform. You can read the earlier posts here: Evolving the Visual Studio Test Platform \u2013 Part 2, Evolving the Visual Studio Test Platform \u2013 Part 1] As .NET Core draws an ever-growing community of developers with existing assets and experiences, it […]<\/p>\n","protected":false},"author":765,"featured_media":45953,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[226,1,252],"tags":[],"class_list":["post-25945","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ci","category-devops","category-testing"],"acf":[],"blog_post_summary":"

[This is the 3rd post in the series on evolving the Visual Studio Test Platform. You can read the earlier posts here: Evolving the Visual Studio Test Platform \u2013 Part 2, Evolving the Visual Studio Test Platform \u2013 Part 1] As .NET Core draws an ever-growing community of developers with existing assets and experiences, it […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/25945","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/users\/765"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/comments?post=25945"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/25945\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media\/45953"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media?parent=25945"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/categories?post=25945"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/tags?post=25945"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}