I useUI-licious for E2E testing.

Disclaimer: I'm one of the creators, so I obviouslyhave 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 createdUI-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.

I used NightwatchJS on previous projects, but I'm tired of Selenium/Java dependency (and I don't really like the Nightwatch API). Now, I mostly use a library built by one of my coworkers:Wapiti.

It's based on Puppeteer, have a clean API and that do the job.

What else? ;-)

fenntasy.github.io/Wapiti/

github.com/Fenntasy/Wapiti

we use Cypress works fine along our Javascript/TS codebase

Been experimenting with Cypress a bit and loved it so far, setting up tests didn't take too long and I got to see what the web pages looked like as the tests were running in real time.

When support for Firefox comes out things will really start looking good

I'm yet to start doing e2e on my new project but I'm going to start from Cypress

This discussion contains a few pointers:

Which framework use for an e2e tests of an SPA?

Rafal Pienkowski

#discuss#webdev#testing#question

I usetapir for E2E testing.

Disclaimer: I am one of the tapir core developers.

With tapir we address the problem of unstable and unmaintainable UI regression tests. It helps the user not to write boilerplate code to have stable tests. There is no need for waits in order to synchronize the test and the System Under Test (SUT).

We invested a lot of time evaluating existing solutions, but none of them pursued our vision how to develop UI regression tests for complex business applications.

tapir is not that wide-spread so far as it has been launched last month. If you are interested consult the tapir websitetapir-test.io/.

I've used Selenium in the past, but Cypress and TestCafe are the E2E frameworks to lookout for these days.

Cypress looks all great and polished, works very well for basic setup and faster than other frameworks but the documentation isn't very clear when you run into issues or need to look something up.

TestCafe on the other hand, might have an unpolished site, but their documentation and the framework is really good and reliable. We're using TestCafe in more than one project at work, especially because we need to test file uploads and TestCafe does it very well.

I would start from Puppeteer , as it feels more code oriented , rather than using a framework/saas platform which for me Cypress is .. today I am using the "old" but working nice set of CasperJS and PhantomJS to cover our e2e UI suites ..

I know that PhantomJS is an old and there is no versions will be released , since the new headless Chrome is taking over the market .. but it does the work and it is pretty easy to develop and include into the CI pipeline which is CircleCi for us ..

Other than Selenium, I findTestCafe to be quite good with lots of browsers support.

At work we’re using Codecept (codecept.io/), it’s supports in our template server.