How do I stop a running MSTest unit test in VisualStudio 2012?
This seems silly, but I can't seem to find a way. I accidentally wrote a unit test that gets stuck at some point and waits forever.
there IS a Cancel/Cancel all button in the TestExplorer window.
(There is a new row of buttons between the search bar and the list of tests, which apparently is easily overlooked.)
Thanks Tyler!
Related
I have been using Google Tests that someone else put together for me and it has worked great...until today. Now when I try to run a test I get a very mysterious problem and I am dead in the water. I had the IT guys even recreate my profile which did have some issues etc - still the same error with little to go on:
Any ideas? Anything. Dead in the water here.
If I don't try to run an individual unit test as I was doing, but simply press F5 from the testing framework (something I had never done actually as I always ran tests through the unit test framework) you can actually find a place where your program pukes.
My program was puking somewhere that had absolutely nothing to do with my unit test, so under the hood, it is clear that the framework needs to run and initialize a lot of stuff that has nothing to do with my tests - in this case it initialized an input stream from a file it could not find way outside of what I was doing. Once I tracked that down, we were good again.
It was very counterintuitive that something so orthogonal to what I was doing caused this. Resharper said they would try to give better error messages in the future.
My setup is as follows:
Visual Studio 2015 Professional 2015
ReSharper Ultimate 2016.1.2
NUnit 3.4.1
Due to palatalisation, NUnit 3 does away with showing Console.Write output on the fly in the test runner window (see this documentation page). This creates an issue when wanting to view output while the test is running as described in this NUnit issue. The resolution (as I understand it!) was to introduce TestContext.Progress to be able to write on the fly to the test output window (in the NUnit console). However, I've tried this with ReSharper and it is not getting displayed at all (even after a test finished running).
Summing it up:
Console.Write gets appended to the test result output after the test finished running
TestContext.Write (short for TestContext.Out.Write) gets sent directly to the test result output, but it is only displayed after the test finished running
TestContext.Progress.Write will be sent straight to the console on the fly
Resharper will display TestContext.Write & Console.Write after the test finished running and TestContext.Progress.Write not at all
Can ReSharper display any output on the fly? Which method should be used for that purpose?
The Console class has a SetOut method which lets you redirect the output to some TextWriter. You can use this inside your test fixture setup.
This worked for me when using the ReSharper test runner on a similar setup:
Console.SetOut(TestContext.Progress);
The code I'm unit testing refers to an appsetting in the app.config file. To cater for this, I've added an app.config file to my unit tests project. If I click the "Run All Tests" icon in the Unit Test Sessions window, all my tests pass.
I have mapped the "ReSharper.ReSharper_UnitTest_RunSolution" command to Ctrl+Shift+Alt+U. If I run the tests by pressing this combination, the tests all run, but they fail to find the appsetting, which comes through as null.
I'm assuming this means that the button click runs under the context of the test project, whilst the command does not, but I can't quite work out what the command is doing.
Have I mapped the wrong command?
EDIT 1: I've also tried using the keyboard shortcut Alt-RUN (Resharper > Unit Tests > Run All), as well as clicking the menus manually, and found that this also causes all unit tests to not find the appsetting and therefore fail. Clicking the Run All Tests icon in Unit Test Sessions (the double green arrow) continues to work fine.
EDIT 2: I realised I should probably be mocking a separate class that fetches appsettings from the config file anyway, so this is what I'm now doing. So now there is no dependence on the config file when unit testing.
There are two things going on here. Firstly, the Run All Tests icon in the sessions window runs all tests in the session, while the Run All Tests menu item runs all tests in the solution. Slightly confusing that they've got the same name, but it does make sense given the context. This is why they give different results.
Secondly, when running all tests in a solution, the app setting might not get found. This is due to an optimisation the test runner makes which runs all tests in the same AppDomain. This avoids the overhead of creating a new AppDomain for each assembly, but has the downside that only one app.config will be used for all assemblies. If it picks the wrong one, your app setting is lost.
You can disable this by unchecking ReSharper » Options » Unit Testing » "Use separate AppDomain for each assembly with tests". Ideally, it should be disabled if any project has an app.config - I've added a feature request you can vote for and track: https://youtrack.jetbrains.com/issue/RSRP-428958
I'm writing and running my tests on VS2010 with mstest. When I want to run a test, or entire tests in a class, sometimes Visual Studio decides to run all my tests.
Why is that? How can I avoid it? Any tips?
May be it is this bug?
http://connect.microsoft.com/VisualStudio/feedback/details/524288/ctrl-r-t-runs-all-tests-the-first-time
Might this be the same problem VS2008 seems to have, where if you use run context (Ctrl+R [Ctrl+]T) or run class (Ctrl+R [Ctrl+]C) it acts as if you used run all (Ctrl+R [Ctrl+]A) the first time after opening a solution? Or at least, it seems so to me. In VS2008 I simply stop the test run when I see this happening and restart the same operation. Then it usually works "as advertised".
No idea if and how this might be relevant to VS2010 at all at this stage...
right click in the body of a single test and select 'run tests' should only run that test
I have the same problem.
My temporary solution at the moment is:
Open Test List Editor.
Type in your test method name in the filter box and filter it.
Check the tests that you want to run.
Right click and select "Run checked tests"
But I prefer the "should-run" as advertised if it works of course. I'm open to other better solutions.
Not quite sure, if this applies to VS2010. In VS2008 running tests in the current context sometimes runs all tests in the solution. It seems, that context is defined by what element was last activated (usually through mouse click). If the last window selected was the code windows containing the unit test source code, then all tests in that class/file are executed. Same with selecting a (unit test-)file in the solution explorer. If however, another windows (e.g. breakpoints) was last selected, then the context is the whole solution.
I'm trying to setup a post-build event in .NET 3.5 that will run a suite of unit tests w/ MS test. I found this post that shows how to call a bat file using MbUnit but I'm wanting to see if anyone has done this type of thing w/ MS Test?
If so, I would be interested in a sample of what the bat file would look like
We were using NUnit in the same style and decided to move to MSTest. When doing so, we just added the following to our Post-Build event of the applicable MSTest project:
CD $(TargetDir)
"$(DevEnvDir)MSTEST.exe" /testcontainer:$(TargetFileName)
The full set of MSTest command line options can be found at the applicable MSDN site.
Personally I would not recomment running unit tests as a part of the compilation process. Instead, consider something like ReSharper (+ appropriate Unit Test Runner or how do they call these nowadays) or some other GUI runner.
Instead of a doing it in a post build event, that will happen every time you compile, I would look at setting up a Continuous Integration Server like CruiseControl.Net. It'll provide you a tight feedback cycle, but not block your work with running tests every time you build your application.
If you are wanting to run the set of tests you are currently developing, Anton's suggestion of using ReSharper will work great. You can create a subset of tests to execute when you wish and it's smart enough to compile for you if it needs to. While you're there picking up the demo, if you don't already have a license, pick up Team City. It is another CI server that has some promise.
If you are wanting to use this method to control the build quality, you'll probably find that as the number of tests grow, you no longer want to wait for 1000 tests to run each time you press F5 to test a change.