What do you use to automate the testing of your Lightning Components?

Question

We've written some Lightning Testing Service tests but its been hard work given the asynchronous nature of the code and that the LockerService blocks access to the underlying DOM. I'm now wondering if it would make more sense to run Selenium tests on the components assembled into an app.

I'd like to know what approach to automated testing of Lightning Components others have taken - please share.

PS

One of the big improvements in Lightning Web Componets looks like testability. So writing those and their tests instead of Aura Components and LTS stuff looks like the best way to go.

Answer 1

I haven't started this yet, but it's on my list of next projects. I don't have an answer as such, but there's been no discussion yet, so maybe this will help to start one...

For my money, I need to get to the point where I am testing the front-end output and back-end data in the same test. The current approach of the Lightning Testing Service service only tests one slice of the layers that make up a Lightning app, and it's not even the one that causes the most problems.

Many of the problems I see are where the framework ends up rendering nothing, or "Sorry to interrupt" which can be due to the markup not the JS.

I also need to test on multiple platforms. In the course of building a Lightning Community with many customisations, I've had failures specific to: Chrome, Safari, and iPad. The last of which was only visible on an physical iPad, not the Safari mobile mode.

I can live with a test run that takes a day and is performed before a major deployment, but it must be repeatable and require nothing more than a button push to kick off.

So, that means that we are talking about some sort of automation to run the front-end, with some sort of test data setup/teardown on the back-end.

Every time I've had chance to talk to anyone in the know, I've asked about this and the consensus seems to be that SF are miles away from releasing anything like that.

If you can live in SFDX-land, then scratch orgs would work really nicely for the backend part. My first stab (which I started but didn't complete) was to use node.js to create a scratch org and populate tests.

From there, you can run tests with Selenium via something like mocha. I think this might require adding synthetic classes to production code to make selectors work consistently - which is distasteful, but not impossible.

I did talk to some "crowd-sourced testing" companies who take a natural English test spec and get real people to run them. This probably saves you the complication of Selenium selectors, but can be quite expensive. And you still need to automate setup/teardown and user creation. Without scratch orgs, I can't see this working at all easily.