Chrome developer console errors

Archive
1

Ok, so there’s like a hundred questions on this and really none seem to work. I’m looking to output the console errors from the chrome browser. What I’ve found out in the world only gives info output to the test running in katalon, NOT the dev console from the browser.

Backstory: I have an app that, when it goes down, will not show a 502 in the UI, just gives a generic message about needing to add things. But, in the console there is a big ol’ 502. How can I get that to output and potentially fail the test so we know it’s there? Do I need to write the api test to check for that? Can I not log the console errors to output/report?

Thanks!

2

Hi Amanda

Let’s agree a few things:

1 - Users (i.e. typical users) never look at the devtools/console.

2 - Automation testing is about ensuring outcomes (i.e. the app UI) meet the objectives of a user using a given app.

3 - API testing is not Automation testing, it tests underlying code interfaces (usually involving a server round trip).

So, for #1, it’s true there are ways to inspect the console in Chrome – but it’s not a web standard (and that’s why Mozilla Firefox does not provide it).

For #2, if you’re meant to be using Automation tests then keep clear of the console and test UI outcomes.

For #3, sure, create an API test and inspect the http response directly. (Personally, I would do it using JavaScript, but that’s just me.)

So the only question left is, what are you trying to achieve? 1, 2 or 3?

1 Like
3

@Amanda Perkins

Have you checked these:
http://forum.katalon.com/discussion/4820/verify-some-javascript-errors-from-console-browser
http://forum.katalon.com/discussion/4841/can-i-log-browser-console-errors
?

I was able to output chrome console messages by following those discussions.

p.s. Before digging in too deep, it is always a good idea to listen to @Russ Thomas advice.

4

Well, Russ, I’m trying to make sure the UI doesn’t return blank, which is what it’s doing some times. Everything looks fine-ish to the user, but it’s really not. So, I’ll probably just write the API test to include with my tests so that we can tell easily that it’s not working and be able to mitigate the issue when it arises.

So, what do you mean by ‘Personally, I would do it using JavaScript, but that’s just me.’? Now, I’m interested.

5

Well, Russ, I’m trying to make sure the UI doesn’t return blank, which
is what it’s doing some times. Everything looks fine-ish to the user,
but it’s really not. So, I’ll probably just write the API test to
include with my tests so that we can tell easily that it’s not working
and be able to mitigate the issue when it arises.

And that’s completely fine, Amanda. You know your intent and you know what you need to do to “mitigate the issue”. Said another way, rules and guidelines are fine, to a point, but when they don’t quite fit, or they seem to actively prevent you from moving forward, you gotta do what you gotta do.

So, what do you mean by ‘Personally, I would do it using JavaScript, but that’s just me.’? Now, I’m interested.

Well, I’m completely happy with making direct API calls from the browser/app to a server using JavaScript (ajax calls, to keep it brief), so that’s what I would do. IOW, I don’t need another API on top to add (potentially) a layer of confusion.

Confession: I’ve never looked at the Katalon API testing stuff - it might be fantastic and perfectly fine, but I see so many requests for help using it, I do wonder. So, yeah… I use JS directly for all webservice-type/API testing.

But again, that’s just me B)

Hope that clarifies?

As to your “sometimes it returns blank” problem…

This, to me, is a signal that the app itself has issues that need to be addressed. I’d first be absolutely certain that the underlying code is handling all asynchronous calls correctly. From your description, I believe it is not. Fixing this is not your job, this is a developer’s job. Your job (at this stage) is to point out that:

  • the app is behaving inconsistently under some conditions making it very difficult if not impossible to test (using automation testing, of course).

Don’t pull your punches - be forthright, tell them, just like that.

Further, if this issue manifests itself in a situation where a user may lose work (i.e. loss of data and/or significant work-time), raise it as a critical bug on the bug tracking system (I assume you/they have one of those?) and be even more forceful as to the untestability of the current state of the app.

Hope that’s helpful.