Live data from Hacker News

Helium: Lighter Web Automation with Python

github.com

21–30 of 53 posts

Re: Helium: Lighter Web Automation with Python

#21
post #10

for lightweight automation outside the browser: https://github.com/elyase/screenium

Very cool! Could be a kind of open-source, text-based (eg recipes are .md with instructions) version of KeyboardMaestro!

I'd love to see such an "open automation" format (could even be more general than pure software, could also automate your IoT or whatever, through extensions)

eg you could have a file "Type my bank login password" for bank websites which doesn't let you use keyboard input but force you to click on stuff, like a self-documented script using .md with code

    # Type my bank login password
    
    ## Trigger
    ```trigger:hotkey
    key: cmd+l
    filter: frontmost-app=Chrome and chrome.tab.url=~mybank.com/login
    ```
    
    ## Deps
    ```ensure-deps
    shell-runner>=1.*
    screen-ocr>=1.*
    python-runner>=1.*
    ```
    Ensure that my system has the proper extensions for the framework, to run all tasks
    
    ## What it does
    This automation lets me input my password in a "click-only" input for my lousy bank UI
    
    ```run:shell /bin/sh:capture-output=password
    echo $(op --vault personal --site mybank)
    ```
    (the above runs the shell script and captures the output as a "password" variable I can use in other scripts below)
    
    ```run:screen-ocr:capture-output=ocr-result
    window:chrome
    ```
    
    ...go on scripting using typescript/python to locate the numbers in the ocr-result

Re: Helium: Lighter Web Automation with Python

#22

How can a wrapper around selenium be lighter than it? A wrapper around an API is by definition heavier (more code, more functions) than using the lower level api. It’s not using less resources. It’s not faster (it has implicit waiting). It’s not less code; it’s literally a superset of selenium? Feels like a “selenium framework” is more accurate than light weight web automation? Anyway, there’s no fixing automation te…

Its use can be lighter. That is, the wrapper can be easier to use. Helium helps with maintaining automation tests as well. click("Compose") is infinitely more maintainable than document.getElementById("eIu7Db").click() . (I just took this example from Gmail's web interface.)

How do you compose low level operations like “click here” into composable modules like:

loginAsUser(user)

id = createBooking(user)

loginAsAdmin()

approveBooking(id)

?

Is it the same as selenium? Do whatever you want your self?

That’s what I’m talking about. Unless you have high level composable modules that let you express high level test activities then your tests will always fall apart.

The syntax of the low level operations doesn’t matter because you will never ever care about a click(“compose”).

That’s not a test.

A test might be:

createEmail()

attachFile(…)

… whatever your bespoke business requirements are.

Having fancy wrappers?

Is it nicer? Sure.

Does it meaningfully improve the tests, maintaining tests?

Nope.

Because at the end of the day the low level operations will be bespoke, nasty, messy and different for each website; that’s why you wrap them up in functions and compose them.

At least, in my experience; this looks a lot like cypress; a high level set of operations with sensible defaults for easy tasks.

…but, practically, I’m skeptical that hiding the low level nasty details actually makes them go away; it’s smoothing them over for the “happy path”; but automation tests are like 90% edge cases.

> It’s use can be lighter

I don’t think that’s the generally accepted meaning of a light weight framework.

…but eh, fair enough. I understand what you mean.

Re: Helium: Lighter Web Automation with Python

#23

Earlier quoted context omitted.

Its use can be lighter. That is, the wrapper can be easier to use. Helium helps with maintaining automation tests as well. click("Compose") is infinitely more maintainable than document.getElementById("eIu7Db").click() . (I just took this example from Gmail's web interface.)

How do you compose low level operations like “click here” into composable modules like: loginAsUser(user) id = createBooking(user) loginAsAdmin() approveBooking(id) ? Is it the same as selenium? Do whatever you want your self? That’s what I’m talking about. Unless you have high level composable modules that let you express high level test activities then your tests will always fall apart. The syntax of the low level…

> I’m skeptical that hiding the low level nasty details actually makes them go away

It makes 90+% of them go away. That's a big win. Try it.

Re: Helium: Lighter Web Automation with Python

#25

Earlier quoted context omitted.

Its use can be lighter. That is, the wrapper can be easier to use. Helium helps with maintaining automation tests as well. click("Compose") is infinitely more maintainable than document.getElementById("eIu7Db").click() . (I just took this example from Gmail's web interface.)

How do you compose low level operations like “click here” into composable modules like: loginAsUser(user) id = createBooking(user) loginAsAdmin() approveBooking(id) ? Is it the same as selenium? Do whatever you want your self? That’s what I’m talking about. Unless you have high level composable modules that let you express high level test activities then your tests will always fall apart. The syntax of the low level…

what you are asking is GEB

Re: Helium: Lighter Web Automation with Python

#26
post #24

Nice work! I looked at the cheatsheet, and it is not obvious to me how to go through two factor authentication during login.

Thanks! Helium only automates browsers. If the 2FA is happening in the browser, then you can use Helium to automate the flow. If it's outside, then that part cannot be handled by Helium.

Re: Helium: Lighter Web Automation with Python

#27

How can a wrapper around selenium be lighter than it? A wrapper around an API is by definition heavier (more code, more functions) than using the lower level api. It’s not using less resources. It’s not faster (it has implicit waiting). It’s not less code; it’s literally a superset of selenium? Feels like a “selenium framework” is more accurate than light weight web automation? Anyway, there’s no fixing automation te…

Its use can be lighter. That is, the wrapper can be easier to use. Helium helps with maintaining automation tests as well. click("Compose") is infinitely more maintainable than document.getElementById("eIu7Db").click() . (I just took this example from Gmail's web interface.)

That's just some superficial changes that often lead to confusion and other negative consequences down the road, especially when not handled carefully.

I would much rather directly rely on Selenium's stable APIs than someone else's wrapped APIs that is opionated and could be incomplete, incorrect, outdated and potentially unmaintained someday. There are always much more resources put into Selenium than these add-ons.

If I really want, I can choose a few APIs that I actually use and wrap them within my codebase. That's more reliable than this.

Re: Helium: Lighter Web Automation with Python

#29
post #27

Earlier quoted context omitted.

Its use can be lighter. That is, the wrapper can be easier to use. Helium helps with maintaining automation tests as well. click("Compose") is infinitely more maintainable than document.getElementById("eIu7Db").click() . (I just took this example from Gmail's web interface.)

That's just some superficial changes that often lead to confusion and other negative consequences down the road, especially when not handled carefully. I would much rather directly rely on Selenium's stable APIs than someone else's wrapped APIs that is opionated and could be incomplete, incorrect, outdated and potentially unmaintained someday. There are always much more resources put into Selenium than these add-ons.…

You can freely mix Helium and Selenium API calls. You don't lose any of the power you are describing when you use Helium.

Re: Helium: Lighter Web Automation with Python

#30

Earlier quoted context omitted.

That's how Playwright works too

Doesn't work for logging into HN: from playwright.sync_api import sync_playwright playwright = sync_playwright().start() browser = playwright.chromium.launch() page = browser.new_page() page.goto('https://news.ycombinator.com/login?goto=news') page.get_by_label('username').fill('mherrmann') # playwright._impl._errors.TimeoutError: Locator.fill: Timeout 30000ms exceeded. I suspect Playwright expects there to be a for…

Depending on when you tried that, there is no such label "username" in view-source:https://news.ycombinator.com/login?goto=news

  username:password:
as they only put text username not and the input is named "acct" (without even the common decency to include autocomplete=username)

So if your script really did write that string into a what it thinks is 'username' then that's arguably one more thing to debug when its wizardry goes awry in some unknown way

Post reply on HN