'No source available' for NUnit project in Visual Studio 2019

fionnaos commented 5 years ago

SpecFlow Version:

[x] 3.0
[ ] 2.4
[ ] 2.3
[ ] 2.2
[ ] 2.1
[ ] 2.0
[ ] 1.9

Used Test Runner

[ ] SpecFlow+Runner
[ ] MSTest
[x] NUnit
[ ] Xunit

Version number: NUnit 3.11.0

Project Format of the SpecFlow project

[ ] Classic project format using packages.config
[ ] Classic project format using <PackageReference> tags
[x] Sdk-style project format

.feature.cs files are generated using

[x] SpecFlow.Tools.MsBuild.Generation NuGet package
[ ] SpecFlowSingleFileGenerator custom tool

Visual Studio Version

[x] VS 2019
[ ] VS 2017
[ ] VS 2015

`Enable SpecFlowSingleFileGenerator Custom Tool` option in Visual Studio extension settings

[ ] Enabled
[x] Disabled

Are the latest Visual Studio updates installed?

[x] Yes
[ ] No, I use Visual Studio version <Major>.<Minor>.<Patch>

.NET Framework:

[x] >= .NET 4.5
[ ] before .NET 4.5
[ ] .NET Core 2.0
[ ] .NET Core 2.1
[ ] .NET Core 2.2
[ ] .NET Core 3.0

Test Execution Method:

[x] Visual Studio Test Explorer
[ ] TFS/VSTS/Azure DevOps – Task – PLEASE SPECIFY THE NAME OF THE TASK
[ ] Command line – PLEASE SPECIFY THE FULL COMMAND LINE

<SpecFlow> Section in app.config or content of specflow.json

<specFlow>
  <language feature="en-US" />
</specFlow>

Repro Project

https://github.com/fionnaos/BowlingKata-Nunit-SDK

Issue Description

With Visual Studio 16.2.5, Specflow extension version 2019.0.36.11860, tests can be successfully built and run, but Test Explorer shows 'No source available'. The same solution in VS2017 does not have the problem.

'NUnit 3 Test Adapter' extension is installed, but when it is uninstalled there is no change. Disabling 'Dotnet Extensions for Test Explorer' does not fix the issue.

Steps to Reproduce

SabotageAndi commented 5 years ago

In Visual Studio 2019 is a new Test Explorer that in VS 2017. The VS Extension doesn't do anything with the test explorer.

fionnaos commented 5 years ago

Hi, I need to confirm with my sample project - and it might be a few days before I get a chance to do so - but I think I have a workaround, which is removing "AfterUpdateFeatureFilesInProject" target and the item group from the csproj.

Since they aren't needed anyway, I wonder if after all this is related to #1457

SabotageAndi commented 5 years ago

AfterUpdateFeatureFilesInProject isn't needed anymore in the latest SpecFlow 3.0 versions.

fabiocardoso87 commented 4 years ago

@fionnaos, Any update on this? Did you solve that?

tzongithub commented 4 years ago

When troubleshooting test explorer issues there is a possibility to change the logging level in Visual Studio (Options/Test/General/Logging-Logging level) to Diagnostic. The detailed output can be found in the Output pane selecting "Show output from:" to Tests.

According to the detailed log the run settings used for the test execution have CollectSourceInformation set to false:

Tests run settings for C:\Work\repros\BowlingKata-Nunit-SDK\Bowling.Specflow\bin\Debug\net461\Bowling.Specflow.dll:
 <RunSettings>
  <RunConfiguration>
    <ResultsDirectory>C:\Work\repros\BowlingKata-Nunit-SDK\TestResults</ResultsDirectory>
    <SolutionDirectory>C:\Work\repros\BowlingKata-Nunit-SDK\</SolutionDirectory>
    <CollectSourceInformation>False</CollectSourceInformation>
  </RunConfiguration>
</RunSettings>.

The root cause of this is unclear. I don't know how the default run settings are calculated, and I'm not sure how/if this is related to SpecFlow.

However, based on this clue I can suggest a workaround for the issue: add a .runsettings file and set the CollectSourceInformation explicitly to true.

Possibilities to add a .runsettings file: https://docs.microsoft.com/en-us/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file?view=vs-2019

E.g. Add a my.runsettings file to the Bowling.SpecFlow project:

<?xml version="1.0" encoding="utf-8" ?>
<RunSettings>
    <RunConfiguration>
        <CollectSourceInformation>True</CollectSourceInformation>
    </RunConfiguration>
</RunSettings>

Add the runsettings to Bowling.Specflow.csproj:

<PropertyGroup>
    <RunSettingsFilePath>$(MSBuildProjectDirectory)\my.runsettings</RunSettingsFilePath>
 </PropertyGroup>

jbrangwyn commented 3 years ago

I just came across this when upgrading an old test suite to the latest nuget release of SpecFlow/NUnit.

I resolved it by cleaning up the project file. For example, changing the top line to be referencing <Project Sdk="Microsoft.NET.Sdk"> (was referencing framework 4.7.1 before) and removing all the config settings that I established were no longer required; newer csproj format hardly needs anything. I did need to re-import all the nuget packages manually.

I had the luxury of another project file to check against. I would suggest creating a new project to see what settings you might need to keep, or do it on a trial and error basis. Hope that helps, sorry I couldn't be more specific.

SpecFlowOSS / SpecFlow