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)
Related
We are having to use the command configuration (to be able to specify the runsettings file that I want to use at the time of running the job) for vstest.console. But now it does not create the results within bamboo. like the vstest.console bamboo task does.
First question, does the mstest parser create that kind of results? Is there a way to do this after running the command prompt. Also, since they both create trx files, can I use mstest parser for the trx created by vstest.console?
Second question, I don't see in my log that it kicked off that step. Is there anything special I need to do to have it kicked off? Especially if the previous step fails?
Also, the .trx logger setting is not renaming the trx to my TestResult.trx file name.
I looked in the list of apps to see if there is a vstest.console version of the parser, there is not. We are using version 6.6.3 ..so we are a bit behind but not sure if this means anything with the parser.
Must have had to do a reboot. I don't know why, but I came back in after the weekend, and the servers have been rebooted, and with no change to what I said above, the results are showing up as expected.
I'd like to ask for some help about setting up the DotTrace plugin for one of our TeamCity builds - so far I've followed the instructions here, and got a build that sometimes works:
https://blog.jetbrains.com/dotnet/2016/02/16/performance-profiling-in-continuous-integration-an-updated-dottrace-plugin-to-teamcity/
However, this is sometimes failing because the build produces two snapshots (snapshot.dtp and snapshot-2.dtp).
After much trial-and-error I've found out that sometimes the reason this fails is because my tests sometimes appear in the first .dtp file (which is the one used by DotTrace's Reporter.exe), and sometimes in the second file.
The other .dtp file appears to be associated with the nunit3-console.exe program, and so should be excluded, since I've added this program to "Process Filters" in the TeamCity build setup:
*nunit3-console.exe
(I've tried every combination here, including entering the fully qualified file path)
This has the effect of adding the following line to the dotTrace.project.xml file when the profiler is run:
<ProcessNameFilter>*nunit3-console.exe</ProcessNameFilter>
My understanding is that this should stop the named process from being profiled (so that the extra .dtp file isn't produced. However when the build is running, I see the following lines in the log file:
[16:01:04][Step 12/14] dotTrace Console Profiler 2018.3.2 build 777.0.20190124.112417. Copyright (C) 2019 JetBrains s.r.o.
[16:01:10][Step 12/14] Profiling in progress...
[16:01:10][Step 12/14] Executable='[file path]\nunit3-console.exe' (non-child) is being passed for filtering
[16:01:10][Step 12/14] Passed filter executable='[file path]\nunit3-console.exe'
This is showing that the nunit3-console.exe is not being excluded, as the filter would suggest.
The closest advice I can find is here, which appears to suggest what I'm doing, but is only for NUnit 2:
https://www.jetbrains.com/help/profiler/Profiling_Guidelines__Profiling_Unit_Tests.html
Does anyone know of a way to ensure nunit3-console.exe is excluded, so that it does not produce a snapshot file?
This plugin produces several snapshots by design and generates report based on all snapshots so filtering is not needed here.
I've created the issue
I am attempting to debug a test, but it is not being executed
Warning 7/12/2012 9:16:53 AM Test run 'xxx#YYY 2012-07-12 09:14:52'
could not be executed. Timed out waiting for the process that runs
tests to initialize.
I however do not have any initializer code at all.
This was working previously, but I just modified Nuget in the solution to allow for Nuget Restore. I am unsure of whether this is the cause or not.
How can I debug through my test again?
I restarted my computer and my tests started debugging fine.
It looks like that Nuget Restore is the cause. In order to confirm it 100% disable Nuget Restore..
Also check if you have any setup methods in your tests (Check attribute [TestFixtureSetUp]). If so, put a breakpoint on them...
I set a breakpoint in my code in Visual-C++, but when I run, I see the error mentioned in the title.
I know this question has been asked before on Stack Overflow (Breakpoints cannot be set and have been disabled), but none of the answers there fully explained the problem I'm seeing. The closest I can see is something about the linker, but I don't understand that - so if someone could explain in more detail that would be great.
In my case, I have 2 projects in Visual C++ - the production dsw, and the test code dsw. I have loaded and rebuilt both dsws in debug mode. I want a breakpoint in the production code, which is run via the test scripts. My issue is I get the error message when I run the test code, because the break point is in the production code, which isn't loaded up when the test starts.
Near the beginning of the test script there is a mytest_initialize() command. I imagine this goes off and loads up the production dll. Once this line has executed, I can put the breakpoint in my production code and run until I hit it. But it's quite annoying to have to run to this line, set the breakpoint and continue every time I want to run the test.
So I think the problem is Visual C++ doesn't realise the two projects are related. Is this a linker issue? What does the linker do and what settings should I change to make this work?
Thanks in advance. Apologies if instead I should be appending this question to the existing one, this is my first post so not quite sure how this should work.
[Update 1] I think Chris O has identified the problem. I'll add a further update if I'm able to work out how to use the project settings to make this work.
It sounds like you are using VC6, since you mention dsw files. I think that is as good as it gets in VC6, you have to manually add the breakpoint after your module is loaded from LoadLibrary. Actually, there might be a project debug setting, so you can specify which DLLs to load when debugging your project, that will keep your breakpoints enabled when hitting F5.
You can also try attaching the debugger after you know the mytest_initialize() has been called, that might keep your breakpoints enabled.
I had this issue sometimes, but always pass this with some code replacement actions.
Here is some guy post, how he had fixed it.
Hope it helps.
In my case i solved this by setting the DLL project containing the breakpoint as Active Project and changed Debug settings for this project (right-click project>>settings>>Debug tab) to point to the project that actually runs and accesses the DLL. "Executable for debug session:" and "Working directory:" should be set to the executable that you actually want to run and its corresponding directory.
Hope this is of any help.
right-click project>>settings>>Link tab
check on Generate debug info
check on Link incrementally
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.