CODEWITHSUNDEEP
.netvisual-studiounit-testingmstestspecflow
Patrick Karcher
Patrick Karcher

Reputation: 23613

In Specflow, new .srprofile names are not accepted by framework

I began having trouble with new .srprofile files a few days ago. Last month, I created 3 custom .srprofile files, for various combinations of parallel v. sequential, different servers, etc. Worked great. I have a corresponding Visual Studio .runsettings file for each, so that the people writing the tests (and I) can choose a .runsettings (and hence .srprofile) in Visual Studio. The selection stays local, so we don't messed each other up switching profiles when checking in code.

The setup has worked great (got over 650 tests using Selenium) until 2 days ago, when I needed to create another .srprofile. When a .runsettings file pointed to any new file I made, then when the solution was rebuilt to discover tests, no test were found. After much trial and error, I can isolate the problem to the name of the .srprofile file. The 3 'original' .srprofiles I made in February all work great (with any valid xml configuration). If I copy and paste one of these working files to a new file (with a new name of course), import that into Visual Studio, change the active .runsettings file to point to this new .srpfofile file, and rebuild, no tests are discovered. When I point back to one of the 3 acceptable file names, all the tests are discovered and listed in Text Explorer.

To summarize: .runsettings files with the exact same content (copied one from another; ExamDiff indicates the exact same content) will work or not (that is, Visual Studio discovers tests) based on whether the name of the file is one of 3 apparently 'grandfathered' names, that I created a couple weeks ago.

Some sort of caching, right? Well, I've cleared out the nuget packages, erased the famous \%TMP%\VisualStudioTestExplorerExtensions\ contents (in my case "\SpecRun.Runner.1.3.0-beta11\"), cleared out the bin\x64\Debug and obj\x64\Debug folders, gotten the solution fresh from source control (which should just have the key files, with no Nuget stuff nor temporary files), rebooted a lot, de- and then reinstalled the specflow VS plugin, waved a dead chicken at the machine, etc. It seems to be keeping track of "good" and "bad" .srprofile names somewhere that I can't find. Anyone understand this?

Update:

Following Meirion Hughes suggestion, I found that in the .csproj file, the "invalid" files were specified thusly:

<None Include="BrowserStack.srprofile" />

while the "valid" .srprofile files were imported thusly:

<None Include="RomulusDirectSequential.srprofile">
    <SubType>Designer</SubType>
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>

I hadn't thought of this because I never touched these settings. It must have been from how they were imported, probably dragging files in v. using the context menu.

Sure enough, in Visual Studio, the Copy To Output settings were different for these files. enter image description here

After fixing that, all was good. Makes sense. The newer .srprofile files simply weren't copied over to where visual studio and specrunner could find and recognize them.

Upvotes: 0

Views: 680

Answers (1)

Meirion Hughes
Meirion Hughes

Reputation: 26428

Make sure the new files are included in the project the same way too:

  • Unload your project (via right click).
  • Edit the project file and look for your valid files.
  • Ensure the xml used to import the working files is the same as the xml for your new files.

There can be quite a lot going on in the project file so its possible there are differences there.

Upvotes: 1

Related Questions