Two Suggestions: Filtered Log Viewer and Filtered Console logs

staff-19

#1

While developing test cases I use the Log Viewer a lot. Sometimes the Console too, but not quite as much. One thing that would improve BOTH would be the ability to filter the display to see messages I’m interested in and reduce the “noise”.

Note: I’m aware of the Log Viewer Info/Passed/Failed/Error/Warning and Not Run switches. My idea is to filter ALL output based on a string I specify. And mostly this would apply to INFO messages which generate a lot of (essentialy meaningless) noise (e.g. Checking object, Checking timeout, Finding web element, etc).

If Katalon would allow user to specify logs as belonging to a new log level “USER” and printed them separately and then allowed user to filter all log entries for “USER” messages of a supplied type, then the Log Viewer would become immensely more usable. I suspect this would involve a new API or perhaps an extension to the existing comment API:

// API...
WebUI.comment(String comment, String userType, String userSubType)

// In use...
WebUI.comment("A regular comment")
WebUI.comment("This is a user comment", "USER", "1")
WebUI.comment("Another user comment", "USER", "XYZ")
WebUI.comment("Yet another user comment", "USER", "NewPageTests")
WebUI.comment("Something different", "USER", "NewPageTests")


Then, if I specify a filter “USER” to the Log Viewer I would see only INFO messages that contain USER:

| INFO USER 1 | | This is a user comment |
| INFO USER XYZ | | Another user comment |
| INFO USER NewPageTests| | Yet another user comment |
| INFO USER NewPageTests| | Something different |

And if I specify a filter “USER NewPageTests” I see only

| INFO USER NewPageTests| | Yet another user comment |
| INFO USER NewPageTests| | Something different |

And then apply the same idea (or something very similar) to the Console.

I hope this makes sense…

Russ


I Shouldn't Need To Say This
Reducing log level for the LogViewer
#2

Hi @4015-Russ,

Thank you for your suggestion. I have logged a ticket and will share with the team for consideration.

Thanks for choosing Katalon products,
Liam


#3

Excellent. Thanks Liam.


#4

+1 for this.


#5

+1

This is a major pain point for our project.

Thanks Liam!


#6

@Katalon Team

Please set a milestone for this - the current weight is at 10 and new suggestions are still appearing periodically:


#7

I posted this in another feed but I think it may be relevant:

Is this any good?

I use part of it in my scripts; I only really use OFF and INFO as I found that WARNING seems to still report INFO level :

import java.util.logging.Level

import java.util.logging.Logger

GlobalVariable.log = new KeywordLogger()

def strLogLogger = GlobalVariable.log.logger

//setting level options

strLogLogger.setLevel(Level.OFF)

strLogLogger.setLevel(Level.INFO)

strLogLogger.setLevel(Level.SEVERE)

strLogLogger.setLevel(Level.WARNING)

strLogLogger.setLevel(Level.CONFIG)

strLogLogger.setLevel(Level.FINE)

strLogLogger.setLevel(Level.FINER)

strLogLogger.setLevel(Level.FINEST)

strLogLogger.setLevel(Level.ALL)

//getting level

def strNewLevel = strLogLogger.getLevel().name


#8

Hey David,

Does this method you have here eliminate the massive amount of info Katalon generally logs? For instance if you set it to INFO is it only gathering info logs into said log file?

I have a custom keyword that includes a big loop and would like to shorten the log file output.

Thank you,

Tyler P.

EDIT: I found this post after making a similar post about the subject at hand here. I’m also looking to just have info be put into the log rather than the thousands of lines of debug info

https://forum.katalon.com/t/only-writing-generated-messages-to-log-file/15809

EDIT 2: I found the below when editing the new log config file which may help in getting this resolved so we can use the other log levels

I found an error associated with my first edit. If I try to use INFO for example I’m getting this error

SLF4J: The requested version 1.7.16 by your slf4j binding is not compatible with [1.6]

I was also pointed to: https://www.slf4j.org/codes.html#version_mismatch


#9

31 :heart: as I write this – and this is not the only thread on this topic!

I mentioned in one of them, there comes a point when a feature requested so often turns into a virtual bug. Surely we are at that stage now?

@ThanhTo @duyluong @devalex88 what else do I (we) need to do to gain some traction on this feature?


#10

Shameless bump.

33 :heart:

Come on, @devalex88… what’s the deal?


#11

Hello everyone,

Just to make sure you guys know about an option to disable logging test steps in Katalon Studio 7.0, which can solve a part of this thread. More details, please read this document.

Cheers

Jass