Stack trace for failed tests in report created by junit-reporter contains color codes.
Something that looks like this in VSCode:
VSCode screenshot
will end up looking like this in the xml report:
Error: [2mexpect([22m[31mreceived[39m[2m).[22mtoBeGreaterThan[2m([22m[32mexpected[39m[2m)[22m
Expected: > [32m100[39m
Received: [31m20[39m
In ADO Tests/Debug tab we then see the same text in the stack trace section.
This started happening when we updated WDIO (and it's dependencies) from 6.5.2 to 7.24.1. We use mocha 8.4.0 and we tried setting the color in mocha options but that did not make any difference.
Is there maybe some junit-reporter settings that we can use to "clean" the stack trace? Or to remove the color codes before report is created?
Related
I noticed that I'm getting what looks like a stack trace vs source code in the main edit area; which forces me to use the 'list' command in the console area.
Why?
Here's the source:
The situation you are in looks like you did a Step instruction while holding the Control key, which will wind you up in assembly language. My guess is that if you click the 0 line in the debug navigator again, you'll see your source code.
I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
Rémi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.
When I run my unit tests in ReSharper's TestRunner, they only tell me the failure that happened, not where in the test! It even truncates a large part of the error message sometimes (because it does not fit on the screen). To work around this, I need to run the test that failed in debug mode and it will stop on the failed line, but this take far more time.
Is there any way to just enable a line number output and full error messages?
Did you activate the output pane in ReSharper's Unit Test Sessions window?
Then you can click on your test and output pane shows all the errors and outputs (from Console.Out.Write(...)). There is usually a stack trace where you can click on a line to navigate to code.
Now I was use NSLog() for debugging inside IDE, Is it possible to styling Log in Xcode ?
Example
Coloring Log
XML, JSON Output in Log console Styling
You can use the XcodeColors xcode plugin to colorize log statements in the Xcode console:
https://github.com/robbiehanson/XcodeColors
It's very easy to use in combination with CocoaLumberjack:
https://github.com/robbiehanson/CocoaLumberjack/wiki/XcodeColors
For example, with Lumberjack, one line of code allows you to set the color for all error messages. You could make them show up in red so they're easily distinguishable from other debug logging.
I'm using Visual Studio 2008. The Trace output is no longer being shown in the Immediate Window any of my forms except the primary form. When it executes code from within another form (called from that primary form) the Trace output doesn't show up. It used to be fine, and one day it just stopped working. I think this is a setting in VS2008. Anyone have any idea what setting this would be under?
It's got a TraceListener in the code, and that hasn't been touched.
Can you do a quick check and see if the second project is compiling in Release or Debug? If it's Release there's a chance Trace won't be defined and Trace output hence won't show up.
Check that you're referencing System.Diagnostics.Trace, and not the Page.Trace TraceContext object. If you're just doing Trace.Write it might be resolving to the wrong place, depending on your using directives.
There's an item under Options - Debugging - General: "Redirect all Output Window text to the Immediate Window". That should do the trick.
Patrick