For years, I have generated my C# unit tests from the VS menu (MsTestV2) and used ReSharper to run the generated unit tests.
The problem is that from time to time (several times a year in my experience), ReSharper loses the unit tests and cannot find them or run them. No circles show up in my VS text editor gutter.
I have tried things such as cleaning the solution, rebuilding it, rebooting Vstudio, deleting my .suo file, clearing the ReSharper Options>General>Clear Caches, deleting/restoring the test project reference to the tested project, adding a new test case manually to the test class, adding a new test class, and probably a few other methods that I cannot remember. None of them helped.
I have a small note from a past instance that tells me to copy all my test files, delete the entire test project, recreate it, add a new dummy test case, and when ReSharper can see the new test in the new project, cut and paste and copy my old test files into the new project.
Naturally, the MsTest runner in Visual Studio finds and runs all my tests properly.
The current test project and test cases have been working properly for many months, and I would rather not rebuild the entire project again. The only recent new thing in the past day or two is an upgrade to VS 16.7.0 and upgrade to the latest ReSharper Ultimate 2020.1.4 built on 2020-07-02. That might be the issue because ReSharper can't find the MsTestV2 tests on other projects too. It would certainly be an easy combination to blame. But my question is really about a reliable procedure for getting ReSharper to find unit tests that it has lost.
Does anyone know of a reliable way to get Resharper to find the current test projects and test cases again?
Related
I installed VSCode for Unity game development a few weeks ago and have been using it as an alternative to my usual setup of VS + Resharper. I enjoy VSCode quite a bit, especially given how fast and lightweight it is.
One problem I have, however, is writing tests. It's standard practice at our studio to create unit tests for certain features we implement, and we so we have an assembly for running tests in a Unity project.
There's a testing .asmdef that references the NUnit framework DLL and the assembbly that has the code I want to test. In VS, if I navigate through the code, it all looks fine. If I switch to VSCode, however, it tells me there's compilation errors all over the place, because VSCode can't see any of the NUnit classes or the classes from the assembly I want to test (in Unity, I get 0 compilation errors even when writing new code).
Is there any VSCode setup I can do to get rid of the compilation errors and write tests normally, or do I have to switch to VS to write tests?
UPDATE: A work colleague helped me out and linked me this extension which clears up the compilation errors.
It looks like it lets me run tests from the IDE, too, but I haven't set it up yet as I just run them from Unity's Test Runner window. This isn't a priority for me, so I'll mark this as the answer.
I've been looking at similar questions on different websites in the hope I could find an answer for it but I've not come across something which has worked for me.
I have a Visual Studio 2019 solution (.Net Framework) which contains Specflow related tests. I can see all my tests in the Test Explorer but when I try to run any of them, I am returned with the error 'Unit test provider already specified'. My test runner was initially Specflow.SpecRun but I have since removed all references to this and am now using Specflow.MsTest - this is to allow me to associate my test cases to one in Azure DevOps. Only after making this change, I am getting these errors.
I have searched across my solution and there are no longer any references to SpecRun; there are no build errors either. The 'Enable SpecflowSingleFileGenerator' setting is set to False, I do have an app.config file but do not have a specflow.json file - I read that that is only needed for .NET Core projects.
Has anyone else come across the above or have any ideas to resolving it as I am a bit stuck.
I was having this problem when I moved from nUnit to MsTest. I want to add few more steps to comments mentioned
Check your feature.cs files and make sure it has onlyMicrosoft.VisualStudio.TestTools.UnitTesting attributes and not nUnit or specrun
Check whether you are using any local.testsettings file in visual studio
Remove nUnit from tools and extensions if you are not using it.
Restart VS, clear temp folder, clean and rebuild
So this may not be the most ideal solution but I created a new project within the same solution, installed the same nuget packages and copied all the files/folders across to the new project. I removed the previous project, cleaned solution and re-built. Tests appear in the Test Explorer and also run successfully too.
So, I am working on a C# project to add unit tests to an existing, very large solution, without previous tests. The design for this is to add a unit test project to the existing solution, referencing the existing project in order to carry out the test logic.
In terms of compiling and running the tests, as I only ever actually update and change my tests as part of this work, I would like to only build and run the test project without rebuilding the large underlying project, which Visual Studio seems to do regardless of whether anything in the original project has changed.
From what I've been able to glean from online, there are options in VS to limit what is actually compiled apart from dependencies, though applying these have made no difference.
EG:
Visual Studio 2008 Unnecessary Project Building
(Different version of VS, but concept is the same)
Is there a way to build and run tests in this way, or is is it simply that VS will always rebuild any referenced projects?
My new workplace has a very large C# solution in Visual Studio 2017 with over 100 projects, of which only one is directly relevant to my job (web acceptance tests via specflow & selenium).
We have intermittent problems with CPU usage & tests not being found in the test explorer, occurring whenever Specflow decides it needs to search for and regenerate test bindings - as it takes some hours to complete, during which Visual Studio is not useful.
From experimentation, I know that if I open only the one project relevant to my work, then specflow finds all the tests in seconds and is immediately useable.
But sadly we need the whole solution to be loaded at least when building new code to be tested.
Is there a way to limit which projects (or paths) Specflow and/or test explorer is searching in for tests, & subsequently generating step bindings from?
I’m hoping for a local settings file (references to .runsettings), but haven’t been able to find any instructions for how to configure this.
There isn't such an option available.
This looks to me we have to improve the VS Extension too handle that many projects.
Could you please open an issue here: https://github.com/techtalk/SpecFlow
There we can discuss, what we can do, to make SpecFlow for you usable.
Using Visual Studio and TFS & preferably Specflow or standard unit test.
I want devs to run ALL unit test as a policy before check in. If a unit test breaks, then vS should stop them from checking in, just like when running across a merge conflict.
I know there're post build scripts that will do this, but really if unit test breaks, I rather that it doesn't get into source control at all. Plus the turn around is rather slow to wait for the full build. And then there's the bickering on who breaks whose stuff.
So no, I want unit test to pass locally before a check in. How would I do that? Yes they can just hit the button, but I like to get them a bit more "incentive" than that.
It sounds like what you're after is a TFS Gated Check-in. This can ensure that the code builds, merges and that tests run successfully prior to committing the check-in. You can read more about it here:
An introduction to gated
check-in
It's worth noting that it's a much slower process than CI builds, so depending on how many check-ins your developers are doing you may be better off looking at a CI build with 'Create Work Item on Failure' enabled and a Project Alert set up to notify the developer that they broke the build.
The TeamCity Visual Studio plugin supports pre-tested commits. I can't speak for TFS, however.