I'm trying to debug some of my unit tests in Visual Studio 2008 and have noticed that breakpoints don't seem to be halting execution.
I kind of assumed that it was as simple as setting a breakpoint and then doing "Test | Debug | Tests in current context" ... but this never actually hits the breakpoints that I've set.
Am I doing something wrong or is this just broken?
Thanks,
Brandon
I had this same problem until I manually attached to the aspnet_wp.exe process first and then clicked on the Debug Tests buttons. Then my breakpoints were finally hit.
In my case System.Diagnostics.Debugger.Break() doesn't stop at testing method.
[TestClass]
public class ContactListTest
{
#region "Constants"
public const string COVERAGE = "CoverageService";
public const string CompanyList = "CompanyList";
public const string ContactList = "ContactList";
#endregion
[TestMethod]
public void GetContactListTest()
{
System.Diagnostics.Debugger.Break();
var ex = new ServiceFilterExpression(COVERAGE);
ex.Expression = new OpBeginsWith("Type", ContactList);
var result = ex.FetchData();
}
}
if you use nUnit you have to do following
start Nunit with the DLL you want to test.
then in Visual Studio go to
Tools -> Attach to Process
choose your nunit process and click "Attach" then it will halt in all your breakpoints
have fun :-)
The official Microsoft workaround/kludge/zomg-I-can't-believe-they-can't-be-arsed-to-provide-this-after-4-years for MSTEST in VS2010, VS2008, and VS2005 is to add System.Diagnostics.Debugger.Break() to the unit test you want to begin debugging from. This works for all projects with debug symbols referenced by the unit test project.
The .NET runtime will prompt you to dump into debug mode (or close the executing unit test program, or ignore the debug line), and (sometimes) allow you to use instance of visual studio that launched the unit test to do so. You can always debug from a new VS instance. Once you hit that System.Diagnostics.Debugger.Break() line, all other breakpoints will be active and hit (assuming they're in the execution stack).
Check the following:
Are the tests marked with [TestClass] and [TestMethod]?
Are you running Debug or Release mode builds? (Doesn't make a huge difference except when it does) Debug is better.
Are you compiling with or without optimizations? Without is better
Try to run All Tests in Solution in check if you hit the breakpoints
and lastly, maybe you have bug and that's why you are not hitting the code?
Related
I am using a an assertion framework called Shouldly for C#.
The code looks like this:
[Fact]
public void SimpleTest()
{
false.ShouldBe(true);
}
This is the same as:
[Fact]
public void SimpleTest()
{
Assert.True(false);
}
However, when I debug the example that uses Shouldly, this happens:
But I want this to happen:
The issue
When I debug with Shouldly, Visual Studio steps into the source code of the Shouldly package. I don't want to see the internals, I just want to see what line of the test my code broke on. I can use the Stack Trace to find what line my code broke on but this slows down my flow a lot.
I remember when I first started debugging with Shouldly, VS asked me if it should download the source files (.pdb?) of Shouldly to debug with, I think I accidentally told it yes.
If I look at the Modules I have loaded in VS, it shows me this:
It thinks Shouldly is "User Code" which is probably why it debugs into this. How can I disable this?
I have this issue every time I change VS version. I've managed to fix it before but this time I can't figure it out.
You can disable symbol loading for a loaded module by:
opening the Module window
searching for the module you want to change
right clicking on it and disabling Always Load Automatically
I would like to write some Unit Tests which simulate the following:
1.) User starts my app
2.) User quits my app (unexpectantly during some operation)
3.) User restarts my app
4.) Unit test then checks to see that my code recovered from this.
Having setup UWP Unit tests using these instructions, I can see that the Unit Test project creates a test UWP app like this in UnitTestApp.xaml.cs file:
Microsoft.VisualStudio.TestPlatform.TestExecutor.UnitTestClient.CreateDefaultUI();
// Ensure the current window is active
Window.Current.Activate();
Microsoft.VisualStudio.TestPlatform.TestExecutor.UnitTestClient.Run(e.Arguments);
Ideally, I would like to somehow kill/quit/abort this Window (or its Frame, or ??) within a single Unit Test, and then restart it and have this Unit test, and the subsequent Unit tests continue.
If this is not feasible, then I would just like to know how others create unit tests that handle an exit and restart of their application.
I would prefer an answer for Visual Studio 2015, but instructions for Visual Studio 2017 would also be helpful.
It's possible to launch and control the app from test case just like winui did,
UAPApp.Launch would help you launch the application.
I didn't see public doc about UAPApp.Launch, The signature can be found in Microsoft.Windows.Apps.Test.chm
For example, for the navigationview tests, TestEnvironment did the magic:
public static void ClassInitialize(TestContext testContext)
{
TestEnvironment.Initialize(testContext);
}
If you dive deep in TestEnviroment, CreateApplication functions would new Application, and finally in Application.cs, testapp is launched by:
return UAPApp.Launch(_appName, topLevelWindowCondition);
I have an nUnit test and I upgraded the project from VS 2012 to 2015. Now when debugging the unit test the debugger steps in to the wrong function. The tests still pass, but debugging isn't working.
When I get to getAString = newClass.ReturnString() the debugger steps in to both .ReturnString and .ReturnInt, then when I get to Dim getAnInt = newClass.ReturnInt() it doesn't step in to it at all. And neither returns a value. Why does it run both functions when I call the first one? There's obviously no parallelism in the code below. When I debug in nUnit it steps in to the correct functions and they both return a value, when I debug in Resharper or Nunit Test Adapter the debugger doesn't work.
Imports NUnit.Framework
<TestFixture()>
Public Class Class1
<Test()>
Public Sub Test_Across_DateRanges()
Dim newClass As New MyNewClass
Dim getAnInt = newClass.ReturnInt()
Dim getAString = newClass.ReturnString()
Assert.That(getAnInt = 5)
Assert.That(getAString = "Why is this breakpoint being hit?")
End Sub
End Class
Public Class MyNewClass
Public Function ReturnInt() As Integer
Return 5
End Function
Public Function ReturnString() As String
Return "Why is this breakpoint being hit?"
End Function
End Class
There are a few root causes to my symptoms, and a few fixes.
Right click solution in Solution Explorer > Properties > make sure eeeeeverything is set to Debug / Any CPU. Select Configuration Properties and the top line will become active. Select Debug, Any CPU, then open Configuration Manager and double check there! And also set Debug / Any CPU in Project contexts.
And most of the things here: Visual Studio 2015 RTM - Debugging not working
Make sure to File > Save As... on the .sln and vbproj files.
I'm pretty sure it was the build to Any CPU.
There are other things to check:
I know that I can attach a currently executing process during a debug session. However, I have not found yet how to debug a process that is launched from the Startup project. I have this process being launched with a few parameters, and I would like to step in its initialization, and verify that the arguments that are being passed are correct. In other words, I would like to step into the startup process, and then, after the new process is launched make that the debugger stops in its first breakpoint.
Can someone show me how to configure this scenario using Visual Studio 2010?
Thanks!
Your question isn't completely clear...but, one way is to insert;
System.Diagnostics.Debugger.Break();
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
System.Diagnostics.Debugger.Break();
}
}
}
A screen will pop-up and you can attach debugger:
Click Debug
Select instance of VS2010 you'd like to use (for example, use the one that has your solution open).
If this isn't what you're looking for, please provide additional details
We have a solution with multiple projects after running the code from VS the output normally seen from Debug.Writeline statements just cease to appear. I mention the multiple projects because the output from one of the projects continues to appear. However, the other project consistently stops showing the output from the statements.
It's starting to drive me crazy. I should mention this is also occurring for a second developer on the project. Anyone seen this before, or have any ideas?
After being tormented by this for years I finally found the cause and the solution in this Stack Overflow question: vs2010 Debug.WriteLine stops working
It seems that Visual Studio's handinlg of debug.writeline can't handle multiple processeses that each use multiple threads correctly. Eventually the 2 processes will deadlock the portion of visual studio that handles the output, causing it to stop working.
The solution is to wrap your calls to debug.writeline in a class that synchronizes across processes using a named mutex. This prevents multiple processes from writing to debug at the same time, nicely side stepping the whole deadlock problem.
The wrapper:
public class Debug
{
#if DEBUG
private static readonly Mutex DebugMutex =new Mutex(false,#"Global\DebugMutex");
#endif
[Conditional("DEBUG")]
public static void WriteLine(string message)
{
DebugMutex.WaitOne();
System.Diagnostics.Debug.WriteLine(message);
DebugMutex.ReleaseMutex();
}
[Conditional("DEBUG")]
public static void WriteLine(string message, string category)
{
DebugMutex.WaitOne();
System.Diagnostics.Debug.WriteLine(message,category);
DebugMutex.ReleaseMutex();
}
}
Or for those using VB.NET:
Imports System.Threading
Public Class Debug
#If DEBUG Then
Private Shared ReadOnly DebugMutex As New Mutex(False, "Global\DebugMutex")
#End If
<Conditional("DEBUG")> _
Public Shared Sub WriteLine(message As String)
DebugMutex.WaitOne()
System.Diagnostics.Debug.WriteLine(message)
DebugMutex.ReleaseMutex()
End Sub
<Conditional("DEBUG")> _
Public Shared Sub WriteLine(message As String, category As String)
DebugMutex.WaitOne()
System.Diagnostics.Debug.WriteLine(message, category)
DebugMutex.ReleaseMutex()
End Sub
End Class
Follow these steps, it works for me
Right click on your project
Select Properties
Select tab Build
Make sure Define DEBUG constant is checked
Hope that helps
I had the same problem with Visual Studio 2010. None of the above solutions worked in my case, but I solved it like this:
Right-click on your project.
Select Properties.
Click the Compile tab.
Scroll down to "Advanced Compile Options".
Change the value for "Generate debug info" from "pdb-only" to
"Full".
No idea what it's for exactly, but now my Debug.Print statements appear in the Immediate Window again I can finally get back to work.
you should try DebugView from Microsoft SystemInternals.
http://technet.microsoft.com/en-us/sysinternals/bb896647
Regards,
Allen
Try checking if Platform for the solution is set to Any CPU and not x86 (or x64). I used x86 to enable Edit and Continue and then lost Debug output. After going back to AnyCPU the Output is also back.
Got this in VS 2015. All of a sudden all Debug.WriteLine "stops working" (not showing in Output window). After going crazy about this for about an hour I found the problem:
1. Right click In output window (output from Debug)
2. Check that "Program output" is checked