marketsquare / robotframework-browser Goto Github PK

• Installation instructions with same depth as SeleniumLibrary, link dependent CLI tools (node, python / pip)

atest should have test targets that represent current web techs.
That means a progressive webapp with asynchronous functionalities and device specific functionalities such as user location.

MVP done at #84

Work on testing this functionality started and tests are currently on master as skipped tests.

There is some unintuitive behaviour with >> and playwright's shadow dom piercing. Some of it is documented here microsoft/playwright#1375 (comment)

Might be better to use this for nodejs:
https://github.com/grpc/grpc-web

Instead or with grpc-tools and grpc_tools_node_protoc_ts

Look at existing SeleniumLibrary keywords and figure out how to prioritize implementing them. Maybe create different tiers like "must have, nice to have, not a priority" or something like that.

Edit: added Tatu's list to this post for easier Kanban tracking

• #50 Select from List keyword
• Deselect from list (Might need to be programmed as custom JS)
• #54 Frame support. No idea how Playwright supports it, but it gets asked pretty often in SL side. Selecting frames and deselecting, no need to implement mistakes done in SL side tough.
• #42 Support for opening multiple browsers/context/page
  • Try out solutions like Switch Context or using Open Browser to create new contexts - ask user input before committing to a technical solution
  • Switch Browser alias_or_index
  • New Browser, New Context and New Page
• Support for toggling check boxes and getting checkbox values.
• Input Password Same as input text but without any logging anywhere in any level.

Rene's Feature requests:

• Type Text Fill Text Instead added a parameter to input text to toggle typing / filling
• Press Key added Press Keys selector *keys
• Wait until Element is condition selector (condition could be clickable, unclickable, visible, invisible, enabled, disabled)

Describe the bug
Does not.

To Reproduce
Take screenshot.

Expected behavior
Does.

Screenshots
Should be in the log.

Is your feature request related to a problem? Please describe.
In many cases it might be useful for the tested page to reveal more info when running inside of our browser. Related discussion from Puppeteer and from Cypress
For instance enabling easier redux state and model access.

Describe the solution you'd like
We should have easy method available for the page to detect our browser when we want to. There should also be an easy method for the page to reveal model/functions whatnot for our library.
There should also be examples and docs that show this.
Would be extremely cool if we could get some autocompletion on the revealed stuff.. that might require similar code generation things that grpcio does.

Is your feature request related to a problem? Please describe.

There must be two style of keywords: asserting and value returning.

This may cause a keyword number explosion like with SeleniumLibrary
Element Should Be Disabled, Element Should Be Enabled, Element Should Be Focused, Element Should Be Visible, Element Should Contain, Element Should Not Be Visible, Element Should Not Contain
And the actual value returning Get WebElement. In this more extreme example that would require 8 keywords.

Value returning keywords are needed for automation, more complex assertions and if the value is later needed as an input to the system under test.

Using value returning assertion has currently fairly verbose syntax in Robot Framework:

 ${actualTitle}=  Get Title
 Should Be Equal  ${actualTitle}  Expected title

Keyword number explosion should be prevented. To make Robot Framework testing tool as good as there can be we should also aim for assertions that are easier to write in Robot Framework than in other languages.

Describe the solution you'd like
Lets built value getting keywords with assertion engine as the last arguments.
This might contain equals operator == Expected title, unequality != Unexpected title, reqexp matching =~ (\w+)xpected title etc.

Syntax would be very short and in my opinion clean:

 Get Title  ==  Expected title

If done correctly, I believe this will result in a less verbose, less complex and more convinient way of doing validators.

If / when node process gets stuck the sanest thing would be for the node side to timeout and send a sensible log message / output through STDOUT or the protocol instead of getting forcefully killed

~~ Easily doable by adding a https://github.com/microsoft/playwright/blob/master/docs/api.md#browsercontextsetdefaulttimeouttimeout playwright context setdefaulttimeout param to the wrapper startup params ~~

After a lot of trial and error I ended up keeping the timeout "state" entirely on the python side (39b9c76 ). This makes handling it easier, since the methods supporting timeout can just default the value to the library.timeout value. Passing the timeout without value through GRPC was problematic because GRPC's optional fields default value is 0. Which also happens to be the value that disables timeouts on PW side.

To-do:

• add timeout parameters and add them to keyword libdoc
• add await .catch on Node side to handle playwright error and pass it through callback

• Figure out why deselecting with playwrights page.select() doesn't work
  • Work around and get a way for users to deselect
    ports assertion syntax
• Select From List By Label, Select From List By Value are now refactored into Select Option By

Discussion happened on #60
At least try using enum aliases for easier Enum value matching than with self-programmed elif tree.

There seems to be cases where either

1. if the test execution is terminated via Ctrl+C
2. if the tests are run in Linux

that the node process for the Playwright wrapper is not terminated correctly.

Need to investigate why, and fix it.

Currently there's some Run Keyword And Expect Errors in our Press Keys test that should be replaced with an actually passing test that succesfully inputs keys with shift. If this is not possible on macOS / some other platforms, we need to document this and if/else it somewhere.

Probably related to puppeteer/puppeteer#1313 . See
https://github.com/microsoft/playwright/blob/master/docs/api.md#class-keyboard
and
https://github.com/microsoft/playwright/blob/master/docs/api.md#pagepressselector-key-options

for more info.

For managing contributor things?

Is your feature request related to a problem? Please describe.
Ease of development is as important as execution performance.
Workflow for iterative trial and error method for developing cases should be faster than with other browser automation solutions. This should be benchmarked and measured.
Describe the solution you'd like
I believe a repl (or jupyter notebook) with very good autocompletion and interaction with browser developer tools should be at least supported. Also ability to stop test and start repl at certain point / condition would be beneficial.
Not all of this has to be done only with this lib. I think we should reuse and gather help and knowledge from other projects too.

Blink / highlight selector shown element.

 elements.forEach((e) => {
    let d = document.createElement('div');
    d.appendChild(document.createTextNode(''));
    d.style.position = "fixed";
    const rect = e.getBoundingClientRect();
    d.style.top = "" + rect.top + "px";
    d.style.left = "" + rect.left + "px";
    d.style.width = "" + rect.width + "px";
    d.style.height = "" + rect.height + "px";
    d.style.border = "1px solid red";
    setTimeout(() => { d.remove(); }, 5000);
 });

Checks if is enum and if not raises AttributeError.
Argument {value} is not one of the allowed arguments {arg.names}

CLOSED: We thought we should probably leave Enum validation to RF since it already does some of it. see atest/test/invalid_assertions.robot for a test

Easy to install and preferably no extra work when upstream of playwright is updated.

Test that common combinations like cut, paste, select-all work with the press keys hotkey stuff.

This is necessary because we need to ensure we pass the hotkey strings correctly to playwright side even with multiple pressed keys etc.

TODO:

• Migration aid for migrating impcompatible locators from SL syntax
• Documentation where our consistent locator default differ from SeleniumLibrary's heavily keyword specific defaults

Details:

Some poking and implementation of compatibility is probably necessary.

We don't want users of seleniumlibrary to need to rewrite their selectors for no good benefit.

However playwright does also expose some advanced selector API's like using selector >> selector to combine different selector engine selectors to select deeper elements. We will probably want to support this in some form to enable advanced use cases, and it is probably quite easy to expose

23.6. notes:

• We might want to break compatibility with seleniumlibrary's default selector behaviour (kw specific defaults)
• Sanest default would be the same as playwright's (css)
• Playwright's selector strategy syntax doesn't play well with robot's support for python named arguments (foo=bar)

Enum conversion will not happen correctly without type annotation.
Right:
assertion_operator: AssertionOperator = AssertionOperator.NO_ASSERTION
Wrong:
assertion_operator = AssertionOperator.NO_ASSERTION

closed as duplicate of #48

https://github.com/robotframework/PythonLibCore will probably help in solving this

RF tests and pytests.
Also static type and style checks.

• Could work as a "hidden" improvement over the "open browser" use (for example for testing different user logins in same test)
• Figure out how Playwright's context's isolation differs from how Playwright's browsers are isolated
• Can we run test suited just in clean contexts within one browser or is launching multipl contexts mandatory?

New Page, New Context keywords, change Open Browser to New Browser

Closed as duplicate of #38

• Probably need user input to decide on what the best API to offer is

• Expose a "append to state" method instead of just a "set" method?

• Instead of using the window to store data expose an rpc endpoint?

• Expose the PlaywrightState object through window.RFBROWSER to browser-side javascript

Is your feature request related to a problem? Please describe.
PageObject and related patterns, issues and comments suggest that direct Python use will be a big part of this libraries success.

Describe the solution you'd like
I want a simple way to access and use library from python.

We need editor support for keyword completions.

Describe alternatives you've considered
Direct Robot Framework side use will severely limit library usability as most automation work will happen in python code. Although tests are written in Robot Framework.

Additional context
Hyvää Juhannusta

• autocompletions @Snooz82 contributed (@xylix cherry picked) in ed26361
• Direct python usage without runtime dependencies on RF #149
  • Added a detection for is robot running and a backup output path for library if robot isn't running
    • Currenty requires utest/output to exist in directory where library is started and used
  • Added robot logger mocking if robot is not running

Currently worked around with a sed run in generaterpc.sh

• Settimeout seems to be a bit async
• 1ms timeout can sometimes be in effect after resetting it to other values.

It should be possible to develop the library also in Windows