#Suggestions for automated E2E testing on Mac?

14 messages · Page 1 of 1 (latest)

stray viper
#

Since E2E testing on Mac sounds like it's just not possible with Tauri Driver or remote debugging port (more info https://discord.com/channels/616186924390023171/1116792966825119814), I'm guessing the only thing we're left with is like an AutoHotKey equivalent for Mac or something similar?

Obviously this is far from ideal and won't give the same type of control, but I'd like to have some sort of automated E2E testing just to make sure my app launches and does a few things correctly on Mac.

Any suggestions for that?

Discord

Discord is the easiest way to communicate over voice, video, and text. Chat, hang out, and stay close with your friends and communities.

willow gazelle
#

In the 1.4 release we'll be exposing our testing utilities, so hopefully you can find testing solutions then that won't rely on something as weird as that

stray viper
willow gazelle
# stray viper That's encouraging to hear! I'd love to not rely on something as hacky as what I...

As far as documentation goes there's not really a lot out there, no. But you can start using them from the dev branch already if you want. There's not a whole lot of utilities exposed, most of them you'll figure out what they do by just looking at their names, like mock_app and mock_runtime. We'll definitely start making more serious documentation on it once 1.4 hits

This is primarily where the test code resides if you wanna check the source code:
https://github.com/tauri-apps/tauri/blob/dev/core/tauri/src/test/mod.rs

stray viper
#

(not so much end-to-end testing of user interaction, button clicks, and all that)

willow gazelle
#

Yea so far it has been purely internal for the sake of just testing the Rust backend side of things. Even when released it's just the internal stuff exposed, so it's considered highly unstable. Testing button clicks and such is a bit of a challenge to set up fully, mainly because it involves setting up a headless webview, and I don't think Wry has anything like that currently

But it's a start to get a full test setup going, now that it's getting exposed it'll be easier to work on it and get more PR's for expanding it

stray viper
# willow gazelle Yea so far it has been purely internal for the sake of just testing the Rust bac...

Great, I appreciate it, any progress in this direction is great!

What I am after specifically is end to end testing on Mac. I have it set up on Windows with the Selenium example working well, but it sounds like it's not possible with tauri-driver on Mac due to WebKit limitations. (https://discord.com/channels/616186924390023171/1116792966825119814)

So that's why I was asking about some sort of method to run E2E user interaction tests on Mac, even though it will be far from an ideal setup.

hasty hill
#

the thread you linked gave a good summary imo.
tbh, i'd tldr that as "no end to end testing on mac".

I'm guessing the only thing we're left with is like an AutoHotKey equivalent for Mac or something similar?
I don't think that'd be a valid approach either but i'm not super experienced with that (anymore).
And using docker to run linux to do the testing sounds like it defeats the purpose too. Though at least you'd be testing webkit which should mostly match between macos and linux

stray viper
#

I guess Linux is a step in the right direction, but yea I'm not deploying to Linux so feels kind of pointless.

May or may not be a valid approach, I'd need to look into it some more, but I'd rather have something that says "sure the app launched successfully and did a thing on Mac" vs 0 automated testing on Mac.

It's sounding like true driver-level integration would require the Tauri team to build their own dist of Safari Webkit like Playwright does, but that sort of defeats the purpose (not testing with the native webview )

hasty hill
#

yeah

#

missing webview specific apis and using a different webkit version (though the last part may not really matter since it differs between macos versions anyway)

vernal pecan
# hasty hill the thread you linked gave a good summary imo. tbh, i'd tldr that as "no end to ...

Why would you say that testing on linux in a docker container would defeat the purpose? Isn't this probably the best option we have for OSX right now? While its true that we wouldn't be able to test that the application runs correctly under OSX, we would at least be able to test a fully running application, wouldn't we? Or am I missing something here? So we would still be able to run tests end-to-end, just not on the target platform (which is sad, but hopefully will eventually be possible)

hasty hill
# vernal pecan Why would you say that testing on linux in a docker container would defeat the ...

Isn't this probably the best option we have for OSX right now?
Yes.
Or am I missing something here?
The last part of my message. "Though at least you'd be testing webkit which should mostly match between macos and linux" -> I meant that in a "so it's still better than nothing" kinda way.
Also you'd really be testing the Linux build/behavior and nothing about macOS, so if the latter is your goal than using docker is pretty useless, if you want general e2e testing without reallyyy caring about os specific behavior then yeah, linux via docker is fine, and again, at least the web engine behaves basically the same so everything inside the window is almost the same as a macos native driver, just not anything outside 🤷