I have an odd problem in VS2008 running unit tests. When I run the unit test using either Resharper or TestDriven, in either normal or Debug mode, the Debug.WriteLine("foo") lines are being carried out twice: ie. in the Output window of VS I can see each line written twice.
If I step through the test, however, each line seems to be carried out once as expected. Anyone know what is going on here? Thanks!
IIRC the Studio's Output window displays not only STDOUT and STDERR but also trace messages. A proper test runner might set up a tracing additionally to writing to STDOUT, something which doesn't happen if you step into the test manually.
Related
What is the best elegant approach for debugging a large E2E test?
I am using TestCafe automation framework and currently. I'm facing multiple tests that are flaky and require a fix.
The problem is that every time I modify something within the test code I need to run the entire test from the start in order to see if that new update succeeds or not.
I would like to hear ideas about strategies regard to how to debug an E2E test without losing your mind.
Current debug methods:
Using the builtin TestCafe mechanism for debugging in the problematic area in the code and try to comment out everything before that line.
But that really doesn't feel like the best approach.
When there are prerequisite data such as user credentials,url,etc.. I manually Declare those again just before the debug().
PS: I know that tests should be focused as much as possible and relatively small but this is what we have now.
Thanks in advance
You can try using the flag
--debug-on-fail
This pauses the test when it fails and allows you to view the tested page and determine the cause of the fail.
Also use test.only to to specify that only a particular test or fixture should run while all others should be skipped
https://devexpress.github.io/testcafe/documentation/using-testcafe/command-line-interface.html#--debug-on-fail
You can use the takeScreenshot action to capture the existing state of the application during the test. Test Café stores the screenshots inside the screenshots sub-directory and names the file with a timestamp. Alternatively, you can add the takeOnFails command line flag to automatically capture the screen whenever a test fails, so at the point of failure.
Another option is to slow down the test so it’s easier to observe when it is running. You can adjust the speed using the - speed command line flag. 1 is the fastest speed and 0.01 the slowest. Then you can record the test run using the - video command line flag, but you need to set up FFmpeg for this.
I have a set of mstest unit tests, which use Trace.Write to collect some debugging information. And when I run it from VS2010 and then go to Test Run Details, there's Debug Trace section where I can see all my messages.
But when I run the same test from command line on the build machine, the trace is not recorded.
The things that I've tried:
Make sure that I'm in Debug configuration
/details command line switch with debugtrace, traceinfo etc options
I know about saving the traces to the file on the disk through the listeners, but I would like to find a solution to write
Has someone had a similar problem?
Try using Console.WriteLine instead. I've had this problem before with MSTest, and using the WriteLine worked for me - in that there was output available in the test result view.
No idea what other things like Debug.WriteLine or Trace.WriteLine didn't work, I never bothered to found out to be honest. (Well, I stopped using MSTest and moved to NUnit)
I recently run into problems when running all my unit tests at once.
I can debug them and run my tests seperate without problems, but when running them all together, the test-run keeps hanging half way through.
This happens:
"Run all tests in Solution"
The first tests parses without problem (slower then usual though)
At some point it gets stuck. Nothing fails, no exceptions, VS just stops running the pending tests.
When stopping the test-run it gets stuck again, and I need to restart VS to abort the test-run.
Normally I would expect a bug in my code, but I haven't made any changes to the code beeing testet since last succesful test-run. The only thing I did was run Performance Wizard - Cuncurrency profiling.
It always stops the same place, when removing some tests from the run it stops a new place (still without actually entering any leftover tests).
I have no clue what is causing this. But seems like I'm having problem with a VS setting rather then a code Error.
Any suggestions? Do Performance Wizard change any settings that might have influenced the way test should be run?
System details:
Windows 7 Ultimate 64-bit,
Visual Studio 10 Premium
This sounds like a concurrency issue. It seems that one test changes the testenvironment in such a way that another test runs into a deadlock. When you remove some tests, the test run order is changed and some other tests get stuck.
So I would look for a concurrency issue regarding your test environment/externall dependencies.
I can't really explain why this works, but it solved the problem!
I reversed the '.csproj' file to an earlier version, in one of the projects that had been in 'contact' with the Performance Wizard, and now my tests works.
ALSO Be aware of that Performance Wizard can change the solution configurations from 'DEBUG' to 'RELEASE' mode in some cases. This was not the case for me, but have been a pain for some of my colleagues.
I have run out of all the posibilities with the next piece of code. The condition in if is false therefore the if should not be executed. But, using the debugger, the execution goes to the second line, which is Response.Redirect.
If False Then
SaveData()
Response.Redirect("Lop_Approved_Results.aspx?lopId=" & lopId, True)
End If
Why this is happen?
Sounds like your source code might be out of date with your binaries. Try doing a Clean Solution and maybe closing down Visual Studio and then re-build all and see if that helps.
If that is really the logic then what your debugger is showing simply isn't what your computer is executing (debuggers aren't perfect). Have you tried closing down, restarting your IDE and cleaning out the project? Do you actually see the redirect occur, as opposed to only seeing the debugger claim to enter this branch?
I'm trying to debug a C++ project in VS 2005.
In debug mode how can i find the previous line that got executed.? i.e Consider the control is in line 5000. How can i find the previous line which got executed before coming to line 5000. Actually there are few goto statements involved. Call stack is just displaying the previous functions which were called.
Though i know it is not a good practice to use goto, this is an existing project which I'm debugging. Thanks in advance.
This information is lost. You should single-step in the code or add logging to know which lines were executed.
If you got to line 5000 by a goto or a jump (rather than by a call), then there is no record of where you came from. You will just have to go back and trace through the code and watch it as it jumps to line 5000.
If you can recompile the source (which I guess you can since you've got debug information) you might want to sprinkle the code with calls to OutputDebugString each with a different bit of text - for example before each label and each goto.
That way when your line gets hit you can check which messages got dumped to the output window to find the execution path.