cannot show the trace message in Output window when running unit test
tried to use the output file in the property setting, but it does not work
Run a unit test method, it cannot show the trace log messages in Output window, but it can show in debug model.
//[TestCategory("XXXNonCritical"), TestMethod]
// public void XXXContainer
// {
//test code
// Assert.IsTrue(metaSettingsData.Any());
// }
expected to see the trace log messages in Output window
there is a link of Output in the unit test result where you can see the log.
Related
I have deployed my flutter app and one user says that a certain part is not working. Therefore, I am interested in finding a way to write all output that usually gets dumped to the console to a string. I could then send this string to myself and use it to debug the problem.
Is there a way to subscribe to all console output? I found runZoned(() => ...) but this seems to only collect certain logs and especially no logs from other isolates.
In theory, it's possible to capture all log output and then store it as a variable. In practice, it's a lot of work and will likely require elevated privileges to access the log stream from within the app itself (which might not even be possible on iOS without a rooted device).
However, I propose that you flip the equation - instead of retrieving the log output, capture your logs before they make it to the console in the first place.
This is where packages such as logger shine. By routing all of your print statements through a logging service, you can set up middleware that will capture your output on the way through the pipe. This way, you can store all of the output without having to mess with things like OS permissions and privileges.
final buffer = BufferOutput();
final logger = Logger(output: buffer);
class BufferOutput extends LogOutput {
final lines = <String>[];
#override
void output(OutputEvent event) {
lines.addAll(event.lines);
for (var line in event.lines) {
print(line);
}
}
}
Usage:
logger.v("This is verbose text");
logger.d("This is debug text");
logger.i("This is info text");
logger.w("This is warning text");
logger.e("This is error text");
logger.wtf("This is what-the-fudgestickles text");
print(buffer.lines);
// Output:
// ["This is verbose text","This is debug text","This is info text","This is warning text","This is error text","This is what-the-fudgestickles text"]
Note: This will work if you want to capture normal app logging output. If you want to automatically capture exceptional log output, you are better off using something like Crashlytics or Sentry to capture and collate those error logs for you since, depending on the error, you can't depend on your app code to be able to run after the error happens anyway.
I observed some kind of Heisenbug, I think: in VS Code, I run the following program:
object Main {
def main(args: Array[String]): Unit = {
print("Start...")
print("...end.")
// println()
// System.out.close()
}
}
If I run the program several times, say ten times, in the debug console tab about two times I get what I'd expect, but eight times I get no output at all.
If I uncomment either of the last two lines I get the correct output everytime.
And if I replace print("...end.") by print("...end.\nBye."), the output text Start......end. is printed everytime, but the output Bye. is only shown sporadically.
Do you know why that happens?
With IntelliJ IDEA I do not observe this behavior: there, I get the "correct" output everytime.
I am exploring the usage of SWTWorkbenchBot to use in my automation of an eclipse-based project. However, something seems weird when trying to get the "Console" view.
SWTWorkbenchBot workbenchBot = new SWTWorkbenchBot();
String consoleTitle = "Console";
try {
workbenchBot.viewByTitle(consoleTitle).show();
System.out.println("Got the Console view");
} catch (Exception e) {
for (SWTBotView view : workbenchBot.views()) {
System.out.println(view.getTitle() + "\t" + v.getTitle().equals(consoleTitle));
}
}
From the above code, I assume one of the following 2 cases holds:
Either the code will exit with "Got the Console view" message printed
Or the message "Got the Console view" message NOT printed because the "Console" view was not found and an exception of type WidgetNotFoundException is thrown and the code inside the catch will be executed. The output should NOT contain the title "Console" or at least, next to all view titles, false should be printed.
Surprisingly, this is not happening. The message "Got the Console view" is NOT printed, yet if you look at the list of the view, you see that there exists a line Console true which means that the SWTWorkbenchBot could not get the console view using the method .viewByTitle() but he knows that exists by checking the .views() content.
The above code works fine for any view except for the Console view. Am I doing something wrong here? Thanks in advance.
If I look into my running Eclipse the View is called "Console (General)". You really should not rely on any names if you have the possibility to reference the view with an Id, check if the follwing snippet will work
workbenchBot.viewById("org.eclipse.ui.console.ConsoleView").show();
Just a sidenote: You should make ui Test code a bit more robust, UI tests tend to fail caused by timings, ui-states, overlapping windows, so fail early with a clear statement why the test failed.
[...]
SWTBotView view = workbenchBot.viewByTitle(consoleTitle);
assertNotNull("Console was not found", view);
try {
view.show()
} catch (Exception e) {
fail("Error occured while opening console")
}
[...]
new SWTWorkbenchBot().viewByPartName("Console").show();
should do the job.
What you see in the UI is the value returned by org.eclipse.ui.IWorkbenchPartReference.getPartName() but not the value returned by org.eclipse.ui.IWorkbenchPartReference.getTitle().
As part of my testing, I am using EventFilter and TestEventListener to listen to log messages. However, doing so causes there to be a massive flood in my command prompt... which makes it very hard to see my tests happening.
Sample Code:
it("should send a welcome message to the user", SystemFortressTest) {
val stub = new SubFortressBuildingPermitRefTraitImplStub
EventFilter.debug(message = "SystemFortressExchange: Received Message: SystemOutput(List(JITMP Booted))", occurrences = 1) intercept {
stub.buildASubFortress(SystemFortressBlueprintRef)
}
}
this code works, but it floods me with debug level data because the TestEventListener prints to STDOUT by default (as it subclasses the default logger which is just straight STDOUT only logging)
I can roll my own logging abstraction that sits on top of Akka's and filter messages from there before it ever hits Akka's stuff... so it wouldn't pollute my command prompt... but that's an awful lot of fuss if there is a similar solution already available.
Problem is, if I use the SL4J Logger, it doesn't work with EventFilter.
What I do is:
akka.loglevel = DEBUG
akka.loggers = ["akka.event.slf4j.Slf4jLogger", "akka.testkit.TestEventListener"]
.. and then in my tests:
system.eventStream.publish(Mute(EventFilter.info()))
system.eventStream.publish(Mute(EventFilter.debug()))
This way:
errors and warnings are reported twice (but those should be fixed anyway :) )
debug and info messages are only reported through slf4j
you can still use eventfilters to check for specific messages (perhaps after unmuting them first)
Note that generally I consider testing for log messages a code smell though - usually better to check for more 'observable' behaviour. Perhaps publish an event to the eventstream.
You can configure log levels or completely turn off the logger likewise with other loggers So when you configure TestEventListener you can specify the logging as below.
akka.loggers=["akka.testkit.TestEventListener"]
akka.loglevel = OFF
Hope this helps
A solution is to create a new listener class that extends the TestEventListener and overrides the print method to either do nothing, or log through your preferred logging solution instead of printing directly to stdout. You then can specify your custom event listener as a logger in your application.conf under the akka.loggers option. (see details at https://doc.akka.io/docs/akka/2.5/scala/testing.html)
So your event listener would be:
package mypackage
import akka.testkit.TestEventListener
class SilentTestEventListener extends TestEventListener {
override def print(event: Any): Unit = ()
}
And you would add the following to application.conf:
akka {
loggers = [mypackage.SilentTestEventListener]
}
If you would turn of logging by altering the log level, or filter noisy logs by using an event filter, then you also wouldn't be able to listen to those logs in your tests, because that is also done with event filters: the logger only executes the filters on the logs until it finds the first one that filters out the log message. If it finds another such filter before the filter used in the test, then your test will never get notified about the log entry.
Another nicer solution would be to implement an event listener that defines its own way of handling logs instead of inheriting and modifying the behavior of the StdOutLogger (since you would expect a subclass of the StdOutLogger to log to stdout...), but this would require more effort than the hacky solution above, since you would have to duplicate the functionality of the TestEventListener.
When using SL4J, here is how we can setup. You will have to turn off sl4j logging to use TestEventListner for testing DEBUG logs.
class MyClassSpec extends TestKit(MyClassSpec.system) {
"MyClass" should "test something" in {
val actor = MyClassSpec.system.actorOf(Props(new MyClass()))
EventFilter.debug(message = s"Testing something", occurrences = 1) intercept {
actor ! "test"
}
}
}
object MyClassSpec {
val testConfiguation = ConfigFactory.parseString("""
akka.loglevel = DEBUG
akka.loggers = ["akka.testkit.TestEventListener"]
akka.use-slf4j=off
""")
implicit val system: ActorSystem = {
ActorSystem("MyClassSystem", testConfiguation )
}
}
I am invoking a compiler command but the compiler messages are not getting displayed in the Eclipse Console View consistently.
I have my launch() method implemented the same way as first code block of
this question; I have the command-line string setup which I use to call DebugPlugin.exec() method. However, unlike the the author of the question above, my output Eclipse console is very inconsistent. T
There is no activity in the console when I invoke the command and the console continues to display the "No console to display at this time." But after invoking the command numerous time and activating different consoles from the drop-down menu, the console occasionally does become active and message is displayed.
I am confused with how the eclipse is behaving and not sure how to resolve this issue. Any comment and/or recommendation would be appreciated.
Thanks!!
--
EDIT
To add some more info, running the external process using External Tools works fine. I add the compiler process c:\path\myprocess.exe in Locations field and the file to compile in the Arguments field within the External Tools Configuration window. When I run it, all the output is displayed fine. It just won't display when I run it programmatically through LaunchConfigurationDelegate class.
Maybe try bringing the console to front programmatically see if it helps:
* Bring the console to front.
*/
public static void showConsole() {
Display.getDefault().asyncExec(new Runnable() {
#Override
public void run() {
IWorkbenchWindow window = CUIPlugin.getActiveWorkbenchWindow();
if (window != null) {
IWorkbenchPage page = window.getActivePage();
if (page != null) {
IViewPart consoleView =
page.findView(IConsoleConstants.ID_CONSOLE_VIEW);
if (consoleView == null) {
IWorkbenchPart activePart = page.getActivePart();
try {
consoleView =
page.showView(IConsoleConstants.ID_CONSOLE_VIEW);
} catch (PartInitException pie) {
CUIPlugin.log(pie);
}
// restore focus stolen by the creation of the
// console
page.activate(activePart);
} else {
boolean bringToTop = true;
if (bringToTop) {
page.bringToTop(consoleView);
}
}
}
}
}
});
}
Finally got it to work. The main change I've made is having my MyLaunchConfigurationDelegate extend LaunchConfigurationDelegate instead of just implementing ILaunchConfigurationDelegate. When observed through the debugger, the launch() method went through similar code path as external process that was launched via External Tools when MyLaunchConfigurationDelegate extended LaunchConfigurationDelegate.
I guess it was lack of information on my part but I wasn't sure which part of the code was more important to share.
Another piece of code that was removed was:
IProcess dbgProcess = DebugPlugin.newProcess(launch, compilerProcess, "XVR Compiler", processAttributes);
...
launch.removeProcess(dbgProcess);
I've added it while attempting different approach in debugging this issue and it actually caused more issues by removing the debugProcess before it has chance to display output to the console.