Any plans for updating this for latest version of .NET Core?

[erlandsona]

I'm using the current 1.0.1 version of the dotnet cli. And whenI run dotnet test I get this output

No test is available in /projects/unit-testing-using-dotnet-test/PrimeService.Tests/bin/Debug/netcoreapp1.1/PrimeService.Tests.dll. Make sure that installed test discoverers & executors, platform & framework version settings are appropriate and try again.

All the examples from the docs use project.json / .xproj format for managing dependencies. I tried using dotnet's updater but it didn't work.

[BrainCrumbz]

Hi there

Are you working with a .NET Core project.json / .xproj project? As the library (actually the runners) do not support yet the recent .NET Core .csproj / msbuild project format arrived with VS2017.

[erlandsona]

It's a .NET Core with .csproj / msbuild. That's why I'm asking. But if I'm reading your comment correctly you're saying that the runners (like for xunit, nunit, etc...) haven't been updated yet?

So what's the timeline for the runners getting updated looking like?

[stefanoric]

+1

[BrainCrumbz]

"Yes and no."

.NET Core projects with .csproj / msbuild / VS2017 are not supported yet. When saying runners, those are only the NSpec runners, I'm not speaking about other test framework runners.

Available option today, for such a project, is to have a simple (.NET Core) console application acting as a custom runner. See e.g. Console App on website, or ping @amirrajan for some simple gist.

We have other "runners", like dotnet-test NSpec console runner and NSpec Visual Studio test adapter, but those have not been ported yet to the new setup. We plan to do that in the future, of course PR are more than welcome. HTH

[amirrajan]

+1 on just making a console app. I think you'll be happier in the long run. I'd be happy to work through any snags you have with getting one working.

[stefanoric]

@amirrajan what are the advantages of having a separate console app, as opposed to seemless integration with dotnet test?

[amirrajan]

advantages of having a separate console app

• It'll work right now (without having to wait for project.json stuff).
• You can customize the parameters you pass into the console app as you see fit, as opposed to having to funnel args through dotnet test [<PROJECT>] [-s|--settings] [-t|--list-tests] [--filter] [-a|--test-adapter-path] [-l|--logger] [-c|--configuration] [-f|--framework] [-o|--output] [-d|--diag] [--no-build] [-v|--verbosity] [-h|--help].
• Generally speaking NSpec is just a library that orchestrates lambdas. How it's hosted is really up to the dev. For me, just making it a simple console app makes the most sense (no dependencies to project structure).

[amirrajan]

Aside: just noting that @BrainCrumbz likes editor and dotnet test integration. I'm not in any way trying to impede that work :-), just providing an alternative (or at least a work around till Microsoft figures out their tooling story for other testing frameworks).

[stefanoric]

I think most developers would prefer first-class integration with the tools they use every day. Working on a large team, it's best to have more options than fewer. Especially in the .NET world, most people live in the IDE, so they expect integration with Visual Studio, Resharper, etc...

I am in the process of shaping the template for how a lot of new asp.net core projects in our team will be developed. I am evaluating a few options for test frameworks, but at the moment the lack of integration with the 'Microsoft' way doing things is not playing in favor of NSpec, when some of the 'competitors' seem to be ahead in the game on dotnet core support. At the same time I like how nspec resembles Mocha in some way, and since we also do a lot of Node it has a great appeal.

If there's any way I can help, I am happy to evaluate if it's doable for me to help this going forward.

[BrainCrumbz]

Especially in the .NET world, most people live in the IDE, so they expect integration with Visual Studio, Resharper, etc...

We had already this chat with @amirrajan , it's somewhere in the issue history 😺 , all this is known and acknowledged since.

The NSpec features that are appealing to your team are the same that worked for us. We've been happily using it with VS2013 and VS2015 on classic .NET framework and, after migration, also on .NET Core project.json from dotnet-test console or VS2015.

Re. help, a couple of possibilities:

1. Figure out what's the current story for test integration & runner in VS2017 + csproj .NET Core.
   There were docs at the time, before RTM Tooling, when Preview 2 Tooling and RC where still around, explaining communication protocol for dotnet-test integration, protocol also valid for VS integration. Know I don't know (yet) how things evolved. For command line, XUnit has moved to a completely owned CLI tool (like dotnet xnunit ....), I think bypassing dotnet test altogether. Don't know what did they do for VS2017 integration. Same thing for NUnit

2. We're porting current VS adapter from VS2013 build environment to VS2015 one. After that, we'll be able to port the actual VSIX extension project to a format known to VS2017. And after this, there are more steps ... but this looks a bit hairy as a task I guess.

BTW thanks for your helpfulness

[amirrajan]

@stefanoric thanks for your input :-)

I completely understand the expectations for first class support in VS.

[erlandsona]

Okay, so I'm down with creating a console application, just not really sure how to follow the instructions when dotnet new consolegenerates a .csproj file instead of a project.json.

@amirrajan, @BrainCrumbz mentioned you could maybe post a simple gist to follow how to get this setup. Something like that would be much appreciated.

I'm new to C# coming from Ruby (so I'm still figuring out tooling), and being able to use something with contexts and an RSPec style DSL would help me out a ton.

[amirrajan]

@erlandsona: this should work: https://gist.github.com/amirrajan/236cbaafef2c7c2195b47c41cbf9c918#file-program-cs

[amirrajan]

@stefanoric: Other food for thought. Having console output (and not being constrained by the overhead of learning VS extension creation) lets me do crazy things like this: http://amirrajan.net/StackTracePreview/#/toc

[ylelan]

Same as amirrajan, working on .net core 2.0 on ubuntu machine.
(gist updated on lower comment)

[GiuseppePiscopo]

@ylelan thanks for pointing that out. Actually yes, this.GetType()... does not fit well within a static method. You could swap that with the following: typeof(Program).... That should fit the bill, what do you think?

[ylelan]

Even better yes
Gist updated https://gist.github.com/ylelan/a8af8e1816675d181d959de73822f1a0