Reporting the DOM during a test case fail?!

The elephant in the room

This is probably one of the most subjective questions I have posted on here…

It may even have an overwhelmingly obvious answer…

But I have run into a slew of test case runs that have ended up failing/flaking, because of various reasons. The most common one? Some test objects that were being waited on, failing on the next action (e.g. clicking on a button after waiting for it to be present), and the test case failing on that step without waiting on the timeOut for the wait-for-element-present…

What’s even more frustrating about that, is that, I have my NewTestListener taking screenshots on fail:

	def sampleAfterTestCase(TestCaseContext testCaseContext) {
		if (!testCaseContext.getTestCaseStatus().equals("PASSED"))
			WebUI.takeScreenshot("Screenshots/Test Case Fails/${testCaseContext.getTestCaseId()}.png")

and when I check out the screenshot, I see clearly the test object that interaction is attempted on, that it complains is not there…!

An attempt at resolution

I am strongly thinking about having the DOM, or a section of it (e.g. the <body>) cloned to an HTML file on test case fail…

How should I proceed with this? What precautions should I take (e.g. deleting all <script> tags from the outputted HTML file)?


I think you’re experienced enough to make that decision yourself. That said…

I dispensed with all WebUI-based interactions within ~3-6 months of using Katalon/Groovy/Selenium and set myself the task of writing my own JavaScript versions of all the “problem” APIs I was having to deal with. I now import that lib for every single interaction step I take. Nowadays, because over time the lib grew and grew, my use of WebUI is paltry compared to you (and, no doubt, others).

To be clear, my issues were not identical to yours, but there is enough similarity to make me want to tell you how I addressed my issues…

If you’re serious about “taking control”, you need to get down to the metal using robust, battle-tested web standards (JS, CSS selectors, the whole nine yards).

1 Like

I made a Test Case:

import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI

// refer to

String js = """
let s = new XMLSerializer();
let d = document;
let str = s.serializeToString(d);
return str

String url = ""
String serializedDOM = WebUI.executeJavaScript(js, null)

File out = new File("out.xml")
out.text = serializedDOM

When I ran this, I got a file “out.xml”:

out.xml (398.8 KB)

This way you can serialize a DOM in browser into a string in Groovy test.



You want to serialize a DOM when your test case failed. I do not know how you can manage the exception. Up to you.

It would be another difficult task to consume the resulting HTML text which is as big as 400KB. It would be very difficult to identify an interesting portion out of boring mass of lines. Up to you. However it is possible to specify which HTML node you want to serialize. This way the resulting text could be far smaller.

I doubt if serializing DOM could be an effective tool for inspection.

1 Like

Hi, I wondered why you have a test listener rather than relying on Katalon’s ability to take a screenshot at a failed step and display in a report? Or is this because you have custom code that might not necessarily trigger a screenshot? As to capturing the DOM - could the time capsule feature be any use?
Fix broken web test objects with Time Capsule in Katalon Studio | Katalon Docs.

1 Like

Because there’s other stuff that needs to happen on a test case exit.

For example, closing my practice profile handler, which controls a spreadsheet of practice profiles. Also, terminating the drivers, that we have custom set up for…