TestMethod: async Task TestSth () does not work with .NET 4.0

Question

I am trying to run asynchronous test methods with .NET 4.0 BCL Async and MsTest.

This installation does not seem to cope with the [TestMethod] async Task TestSth () due to the lack of an entry in the test case explorer. After changing the signature on async void, I can run a test case, but with the wrong result (no errors are reported at all).

I saw attemt on testing Async Task test modules with TFS 2010 , but I think there should be a nicer way to solve the problem.

Any suggestions?

Answer 1

The async can only be used with the .NET Class 4.5 MSTest class library.

If you cannot use .NET 4.5 for any reason, you will just have to live with manual tasks waiting.

And even if production code (i.e. the code under test) cannot use .NET 4.5, why can't the test project do this? If you already have VS 2012+, then .NET 4.5 will be installed on your development machine.

Answer 2

Here is a workaround that works for me. It was a little difficult to understand, but finally, all unit tests against my .NET 4.0 libraries are detected and displayed in Test Explorer, launched and passed, and they are all written as normal async Task methods, without any special test runners, wrappers or third-party addictions.

• Change the target structure of your unit test project to .NET 4.5.
  • Yes, you must do this even if the project refers to the fact that you are testing the target .NET 4.0.
• Remove the Microsoft.Bcl , Microsoft.Bcl.Build, and Microsoft.Bcl.Async NuGet links from the unit test project. If you have not added these links, just do not add them to the unit test project.
• Add System.Runtime.dll and System.Threading.Tasks.dll to the unit test project as related files in the project root directory.
  • Right-click the unit test project in Solution Explorer.
  • Add> Existing Item ...
  • Go to the solution packages folder and find the net40 package folder for Microsoft.Bcl ; e.g. ... \ packages \ Microsoft.Bcl.1.1.10 \ lib \ net40 \
  • Select All Files (*. *) In the drop-down list of file types.
  • While holding down the Ctrl key, left-click System.Runtime.dll and System.Threading.Tasks.dll to select them.
  • Click the small drop-down arrow on the Add button. (Do not click the Add button.)
  • In the drop-down list of the Add button, click Add as link . Both assemblies are now visible at the root of your project.
    • You must leave assembly links at the root of your project. Do not move them to a subfolder.
    • If your project is under source control, you may notice that these related files are marked as excluded (and if not, they should be.) The NuGet package folder in which these files are located should not be checked for source management. Since they are only linked files, anyone who discards your changes should not have any problems after restoring their NuGet packages.
• Select both linked assembly files in Solution Explorer (Ctrl + left-click) or simply follow these steps for each file separately.
• Right-click on any of the selected files and select Properties . The Properties window opens.
• Set the Copy to output directory field to Copy if it is newer.

Your unit test project file should now have something similar to the following.

 <ItemGroup> <Content Include="..\..\packages\Microsoft.Bcl.1.1.10\lib\net40\System.Runtime.dll"> <Link>System.Runtime.dll</Link> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> </Content> <Content Include="..\..\packages\Microsoft.Bcl.1.1.10\lib\net40\System.Threading.Tasks.dll"> <Link>System.Threading.Tasks.dll</Link> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> </Content> </ItemGroup> 

What is it!

Just keep in mind that your unit test project is for .NET 4.5 (or a higher version if you want), and so unit tests can use async methods and any other .NET 4.5 features. There should not be any conflicts with the .NET 4.0 assemblies that you are testing, but if you find conflicts, perhaps because you have redefined some types for the new Framework / C # functions and made them public, which caused conflicts when you try to use the same types in their unit tests. The best solution is to simply make these types internal to the projects you are testing.

Edit:
After completing these steps, you may receive assembly warnings:

All projects that reference My.csproj must install the Microsoft.Bcl.Build nuget package. See http://go.microsoft.com/fwlink/?LinkID=317569 for more information.
{Root} \ packages \ Microsoft.Bcl.Build.1.0.21 \ build \ Microsoft.Bcl.Build.targets

To avoid these warnings, simply edit the unit test project and add the following metadata element to each project link that points to the project that references Microsoft.Bcl.Build .

 <Properties>SkipValidatePackageReferences=true</Properties> 

For example:

 <ProjectReference Include="..\pcl\pcl.csproj"> <Project>{664a9e98-fac7-4567-a046-0dde95fddb48}</Project> <Name>pcl</Name> <Properties>SkipValidatePackageReferences=true</Properties> </ProjectReference> 

A full explanation can be found in the marked .targets file included in the Microsoft.Bcl.Build package. Here is the full comment for your convenience.

BclBuildValidateNugetPackageReferences

This goal confirms that any Nuget packages installed in the current project are also installed in projects referring to the current project.

This is necessary because Nuget packages not only contain simple links. Installing the package ensures that 1. The correct set of links for the target structure is added.

2. Configuration file conversions apply
3. The project installation scripts are executed.

For all packages listed as installed for the current project in the package configuration, if the package identifier matches the one specified in @ (ValidatePackages), make sure that the same package is installed in the link project.

This link can be disabled for the project link by setting the link value SkipValidatePackageReferences = true:

 <ProjectReference Include="..\pcl\pcl.csproj"> <Project>{664a9e98-fac7-4567-a046-0dde95fddb48}</Project> <Name>pcl</Name> <Properties>SkipValidatePackageReferences=true</Properties> </ProjectReference> 

This target can be disabled for all project links by adding the following:

 <PropertyGroup> <SkipValidatePackageReferences>true</SkipValidatePackageReferences> </PropertyGroup>