I use UI-licious for E2E testing.

Disclaimer: I'm one of the creators, so I obviously have an Opinion™ ;)

I've used UI-licious to test UI-licious itself. And for a very convoluted reason, also used it to automate Docker deployments for UI-licious via Rancher's UI, but... that's leave that story for another time.

Free and open-source tools that I like

Codecept: The biggest win for me here is how easy to learn and readable the tests are. This makes the tests really easy to maintain, which is important to me as I worked on enormous projects with heavily complex user interfaces and very deep user journeys. From time to time however, I find Codecept not as elegant is I hoped it to be, and had to fallback to hard coding CSS selectors and using magic waits to get around async events. And as far as I know, there isn't a way for me to split my tests and run them in parallel to finish my enormous test suite faster. It's still the best free open-source acceptance testing framework I know of, and I'd recommend it.

Webdriver.io: This is what I end up using when I can't wraggle Codecept into testing certain cases for me. Webdriver.io is the underlying library for Codecept.js, and exposes Webdriver protocols for you to do the really nitty gritty things, but it's not something I'd recommend for everyone and every project.

Cypress.io: What I really like about Cypress is that conceptually they are building the architecture from the ground up rather that simply creating yet another a framework that adds syntactic sugar over Selenium, which solves a lot of problems that made tests flakey. Reports look great. And syntax is like Mocha, so it should be easy to learn. It is free unless you want to better reporting, which will start from $99/month after beta. Which means that there's someone working their ass off full time to make sure this testing tool works - reliably - because they are not starving open-source devs. The only deal-breaker might be that they only support Chrome at the moment.

Warning, opinion™ ahead

I created UI-licious because I have an opinion on how E2E front-end testing should be that was not being fulfilled by other testing frameworks:

1. You shouldn't be hard coding tests to the UI: And hard-coding CSS selectors and magic waits are a huge no-no to me. Hard-coding is a code smell, and guess what? Tests are code! Hard coding is what's making your tests flakey. And in huge applications, ID-ing all elements for testing is a pain, and the UI designs are probably going change (and the IDs will too).

2. E2E testing is about the users' journey: Making sure your app works isn't simply about filling forms and pressing buttons. It's really about whether the user get what they want from your app. That's why I prefer BDD-style tests. They describe the user's journey and are essentially living-documentation of your app. This makes it really easy to author and maintain tests. I'm no fan of the PageObject concept which comes from Selenium because it's difficult to read and maintain. And if you go to Selenium's website, you'll find that it's not tool meant for testing, because here's what it first says "Selenium automates browsers. That's it!". It's simply a browser automation tool. Also, while the modern async/await is great my front/back-end work, it makes tests terribly unreadable, and using a Javascript testing library that does co-routine sync like Codecept would be better.

What I've done with UI-licious is to create tests that describe the user journey from their perspective, without any knowledge of the actual implementation of the UI.

Here's what logging into Github looks like:

I.goTo("https://github.com");
I.click("Sign in");
I.fill("Username or email address", "brucewayne");
I.fill("Password", "iloveselina");
I.click("Sign in");
I.see("brucewayne");

It's simple, concise, readable.

And independent from your UI code, so you can stop fixing broken tests. And this means you can write less and test more, because the same test can be used for multiple designs. Just write one test for testing the same flow on desktop or mobile.

UI-licious works by using static code and contextual analysis to infer which element on the screen to test.

But what if there's several things on the page that looks the same, how does the test engine know what do interact with? We've got that covered.

And that's my two cents.