Add support for .NET Core testing

[jcansdale]

.NET Core CLI test communication protocol
https://docs.microsoft.com/en-us/dotnet/articles/core/tools/test-protocol

[plioi]

It's possible that the dotnet test client/server handshake described in that link would allow TestDriven.NET to sidestep things like the lack of AppDomains in .NET Core, by playing the role of the IDE. A test framework's own dotnet test implementation would then run instead of a TestDriven-specific plugin per test framework.

[plioi]

It may be easier to see what the handshake would be like by seeing xUnit's side: https://github.com/xunit/dotnet-test-xunit
https://github.com/xunit/dotnet-test-xunit/blob/master/src/dotnet-test-xunit/CommandLine.cs#L223

It's a handful of JSON messages going back and forth.

[jcansdale]

You're right, it's handy there is a standard wire protocol for dotnet core testing. Hopefully there is a standard naming convention for tests as well. I look forward to getting this working. :)

[jcansdale]

Looks like the 'Microsoft.Extensions.Testing.Abstraction' package on NuGet could be useful as well. Crazy number of dependencies though!

Also, the NUnit runner for .NET Core:
https://github.com/nunit/dotnet-test-nunit
https://github.com/nunit/dotnet-test-nunit/blob/master/src/dotnet-test-nunit/CommandLineOptions.cs#L233

[jcansdale]

Current version of TestDriven.Net can't see assembly for .xproj projects.

I believe the following should work:

        static string findBuiltFile(Project project)
        {
            var outputGroup = project.ConfigurationManager.ActiveConfiguration.OutputGroups.Item("Built");
            var urls = (object[])outputGroup.FileURLs;
            foreach (var url in urls)
            {
                return new Uri((string)url).LocalPath;
            }

            return null;
        }

[jcansdale]

I'm wondering what the best way to detect a .NET Core assembly from for a classic .NET application. I can load the .NET Core assembly fine and reflect on it.

If an assembly references "System.Runtime", is that a clear indication that it's a .NET Core assembly? Is "System.Runtime" the .NET Core equivalent of mscorlib?

[jcansdale]

https://twitter.com/bradwilson/status/749613448565104640
"No. System.Runtime started with PCLs."
@bradwilson

I'll maybe look for the following instead:
[assembly: TargetFramework(".NETCoreApp,Version=v1.0")]

[jcansdale]

Picking up from conversation with @bradwilson at #4.

Given that you're doing that, you should look at the special hooks already required by the Visual Studio test runner, and see if you can reuse them.

I'm planning to initially make it compatible with this interface. I've done some experiments and it looks like the following should work (same with class and namespace):

dotnet test -designtime -method myclass.mymethod

There are definitely optimizations that would make it faster (Microsoft.Extensions.Testing.Abstractions seems to have a crazy number of dependencies).

I'm surprised. I expected you to ask people to code to your existing API, just with a .NET Core compatible API surface.

This is pretty much what I've done with the ad-hoc runner. It would certainly make sense to clean this up and allow people to implement as an alternative to the VS interface (say with a -tdnet switch). This would make tests run faster because there's no need to use the symbol reader or pull in so many dependencies! I might make it a single source file that could be compiled as part of 'dotnet.test.xunit'.

[jcansdale]

TestDriven.NET-4.0.0_Extraterrestrial_Alpha.zip

I have finally got support for running ad-hoc test methods working with .NET Core. It doesn't know about xUnit or NUnit tests yet, but this is a good start.

Please give the attached (above) installer a try and let me know how you get on! Simply target any .NET Core method (or property) and 'Run Test(s)'. 'Test With > Debugger' doesn't work yet. You can also return an object and it will dump its properties and fields. 🚀