[wokwokwok]

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 tests with fancy APIs.

No matter what you try to do, if people are only interested in writing quick dirty scripts, you’re doomed to a pile of stupid spaghetti no matter what system or framework you have.

If you want sustainable automation, you have to do Real Software Engineering and write actual composable modules; and you can do that in anything, even raw selenium.

So… I’d be more interested if this was pitched as “composable lego for building automation” …

…but, personally, as it stands all I can really see is “makes easy things easier with sensible defaults”.

That’s nice for getting started; but getting started is not the problem with automation tests.

It’s maintaining them.

[mherrmann]

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.)

[n144q]

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.

[mherrmann]

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

[wokwokwok]

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.

[mherrmann]

> 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.

[Zardoz84]

what you are asking is GEB

[pryelluw]

> but, personally, as it stands all I can really see is “makes easy things easier with sensible defaults”.

“Lighter” may be used as an alternative adjective to the word easy or easier. Your post, which comes off as very rude, misses the point of how the project is marketed.

At least the OP did not call it Python automation for humans …

[wokwokwok]

> “Lighter” may be used as an alternative adjective to the word easy or easier

That is, again, not common usage, there’s a word for easier to use; it’s “easier”. but whatever. It doesn’t matter; it’s just branding.

My point however, is that making easy to use frameworks for test automation is fundamentally misguided, and the responses like “try it, you’ll be amazed it makes all the problems go away” is the type of “drinking kool aid” that’s displays a deep lack of understanding of the problem space.

Doing easy things does not solve doing hard things; not here. Not in go. Not in rust. Not ever.

So, my point was (and is):

How does this address doing hard things because as someone who is familiar with this space and has tried it, I can’t see anything that helps with the hard things and no one who is heavily invested in automation realllly cares about doing easy things.

We can already do easy things

Another way of doing easy things is like using prettier or not; it’s a style preference.

So, is that what this is?

Selenium with a function calling style preference, or something that actual helps building automation?

There’s nothing wrong with making tools that make superficial cosmetic changes to the way you do things.

…but, that’s not how the project is marketed; as, at least, I’ve understood it.