End-to-end test suite for Apache Iggy Web UI

[rustworthy]

As per this Discord discussion opening an issue to track work on the end-to-end tests for Web UI.

I am suggesting to use fantoccini with chromedriver to test Web UI. Example/reference of setup, utilities, and break-down
can be found here.

We can break the work into a few iterations for easier reviews:

• e2e tests setup (dependencies and utilities);
• test authentication (I think I might combine it with the first step, but let's see down the road)
• test main scenarios/pages (we can outline these later on)

The tests will be located under iggy/core/server/tests.

cc @spetz

[spetz]

@rustworthy thank you for the discussion, I was just wondering if Playwright is still a thing, as for Web UI we don't need to (ofc we can) focus on writing the tests in Rust?

[rustworthy]

@spetz I guess Playwright works similar to fantoccini under the hood? not sure if it provides benefits over writing tests in Rust

[spetz]

@spetz I guess Playwright works similar to fantoccini under the hood? not sure if it provides benefits over writing tests in Rust

I'm not an expert in this matter, so I can't say for sure :) My point was, since UI is written in TS (using Svelte), shouldn't the tests also be part of the existing /web module and use the same language?

[rustworthy]

I do not think they should (but they of course can), since the e2e test suite is essentially another application sending commands to web driver and inspecting responses, right? And so why should this use the same language as the one powering the user interfaces?

Maybe it's easier to adjust tests whenever one is working on the web UI code w/o switching to a different language. Also maybe colocation makes it easier to arrange for e2e tests to be launched whenever changes are detected in the web namespace. But for me personally neither of these arguments is a big deal or strong enough to not use my language of choice and it's ecosystem. But that's me and also there may be other arguments.

In other projects, using Rust and hosting tests alongside the server allowed me to re-use the database drivers (e.g. sqlx) to inspect what we persisted. Also launching a dedicated backend (server) from the test context setup (for better isolation) is very straightforward when they use the same language :)

[spetz]

Ok, fair enough, I was just curious about the reasoning :) Feel free to build E2E tests in Rust, interested to see the outcome!