When is WebDriver BiDi support coming to Katalon?

Selenium 4 upgrade will get us BIDI support. That will happen this year.

Bidi is exciting and want to see all the different ways we can use it. I think we can reimplement some keywords far better in BiDi and provide better logging and report information.

That being said, I’m thinking of upgrading Sel 4 first, doing everything possible to introduce minimal or no breaking changes (perhaps a migration script), and then in a subsequent release improve items with all the power we get from BiDi (more reports, MAYBE removing the Katalon extension on execution!!)

Thoughts?

-Philip B
Sr PM Studio

Also @kazurayam you can tag me instead of Jass, she’s not the PM anymore.

2 Likes

Tagging @mike.verinder @Coty

My advice, FWIW…

Do it quickly. Release a “long-term alpha” with Se bound to a minimal set of APIs (bunch of setters/getters and (joy of joys) all the events/handlers you can muster).

That way, you can be ready sooner, and build a path to a full release with a new and battle tested core set.

1 Like

Sweet ! This would be a great add

Asking for a friend…

:wink:

Oops. This was supposed to be up top :roll_eyes:

Would you consider support for existing Katalon keywords as part of MVP.

I think increasing reports could come in a later release

Hmm. Good question.

Opinionated/heavily biased answer:

I think I’d expect WebUI.* to be present and working. Perhaps Mobile can wait a little longer?[1]

As soon as possible, event binding/handling. ← the raison d’etre AFAIC.

And if I can code up my own custom events/observers[2], placed in the page, results sent “out” to the Katalon groovy script… sounds like heaven. Possible?

But MVP? Really hard to say. I use a highly specific subset of Katalon… hence, biased and opinionated. You might want to ask a wider audience.


[1] Only because I think early dev is best done on a pro dev desktop (I have a 4-screen setup, for example).

[2] Yes, I could inject that stuff now, but it’s not the same as having a bidi connection across the AUT/WebDriver divide. I wrote ONE sentinel/guard/wait routine split across Groovy&JavaScript – works great, but man, complex and tricky code to maintain.

I have my own reporting system…


START - 2024-03-26 12:47:49 (EDT)
Test Case - Test Cases/Pages/Home/Test Home Upload-Import Results
Associated Bug IDs - [23882, 26745]
BuildNumber - 32974
TargetServerURL - https://you.gotta.be.joking/
ConnectionString - [ConnectionStringLIMS]
Login - "Justin"
1 - Home page
2 - Upload the BAD results CSV file
2.1 - Click the Browse file button
2.2 - Click the Upload file button (Save)
2.3 - Wait for the response ^There was an XSD error processing this file
3 - Reload the page
4 - Upload the GOOD results CSV file
4.1 - Click the Browse file button
4.2 - Click the Upload file button (Save)
4.3 - Wait for the response "^File uploaded OK"
5 - QBE up to five times for SAMPLE_STATUS = "C"
5.1 - Navigate to sampleUpdate
5.2 - Perform the QBE
5.3 - Check SAMPLE_STATUS is "C"
5.4 - Navigate to sampleUpdate
5.5 - Perform the QBE
5.6 - Check SAMPLE_STATUS is "C"
5.7 - Navigate to sampleUpdate
5.8 - Perform the QBE
5.9 - Check SAMPLE_STATUS is "C"
5.10 - Navigate to sampleUpdate
5.11 - Perform the QBE
5.12 - Check SAMPLE_STATUS is "C"
ERROR at or near: 5.12 - Check SAMPLE_STATUS is "C" Failure: basePage.qbeUntil reached maximum attempts! (3)
END - 2024-03-26 12:49:32 (EDT)
DURATION - 1 minutes, 43.096 seconds
EXIT TEST

Whatever you provide, I may not use it. IOW, I may not be the best beta-tester for that part. But what do I know, yours might be better :wink:

So how does this work, @philip.becker ? You ask me questions and I answer best I can. I ask you questions and…?

Did I head the wrong way down a one-way street?

Can you give me more details on what you want to use event binding/handling?

From 10,000ft…

Page with editable table/grid of cells ← 600+
Cell edits are saved via ajax.
Watch ui changes as the save process progresses.
  Catch (broadcast to test code) the async promise-complete
  Ensure ui reverts to “normal”

At the moment, that’s a dumb WAIT/while loop involving AUT flags not designed for testing purposes.

So, from TC code, via BiDi, register an observer (delegate) in the AUT on the parent table/div (begin, error, complete handlers)

Observer calls back to the remote (Katalon Groovy TC) when:
 – the save (promise) event begins
 – on issue occurring, calls registered error handler
 – the save resolves/completes

Obviously, the TC (groovy) thread will need to wait until all observers stop (with success or fails/errors).

I can do all this now in Groovy/JavaScript but it’s messy. Biggest problem is timing. On a superfast system, the ui changes may not be evident at all, to human eyes. But with BiDi wired up correctly, that shouldn’t matter.

Second example:

Register an observer for any and all “spinners” (busy indicators). Very similar architecture to the above, but events are spinner-shown (+backdrop), spinner-removed(+backdrop)


You’ll need to develop protocols around which the above can be coded in TCs.

Brainfart, pseudocode…

@Bidi_promiseobserver
new SaveCellWatcher()

where SaveCellWatcher is a class implementing methods for an interface like failure() and success() which match the AUT’s promise code.

It sounds like we can support this just by upgrading to Sel4 and not having to provide a keyword for it - since it appears pretty custom, you’d just get the webdriver and do your thing. Is that correct?

I’m looking at BiDi to remove a lot of our runtime dependencies on extensions as well as a lot of other items that are now available.

I wouldn’t know about that, but sure, maintaining deps-debt is always a good move.

To try to stay abreast of all this, I’m having the W3C issues emailed to me: