Front-end testing can overwhelming very quickly with so many browsers and resolutions to test. And the permutations of states your UI can be in depending on the ifs and the elses of possible user actions can go up pretty fast too.
Manually testing the UI is time-consuming, and pretty damn boring too. And if you are like me when you are bored, you'd be testing with half-a-brain and very likely to miss a bug.
You should save yourself now, please automate testing.
Just so you know, I'm one of the creators of UI-licious, which is a UI test automation solution, so I'm obviously a strong advocate for automating tests on the front-end. But for good reasons - had my own horrors on software testing.
Anyway, over here at UI-licious, everyone tests. I mean everyone. No, it's not your dedicated QA's job to do ALL the testing. Everyone's responsible for making sure they do their work well, and not leave it to others to deal with crap - especially not the users or customers.
In production: We have critical front-end tests for production that run every few minutes to make sure critical services are fine. We set up Telegram alerts so that if things go very wrong, we can respond quickly. The nice thing about UI tests is that they can catch problems downstream in the backend and infrastructure as well.
In staging: We run the full suite of front-end and back-end tests on staging before deployment.
During development: We hook up critical tests into the build pipeline so that bad code gets automatically rejected.
Code reviews: Usually we do code reviews to clean up code smells. We also check for edge cases and add in the test and the code for for missing edge cases. It's a good opportunity to train juniors how to design and test their code.
To TDD front-end development, create your UI mockups/wireframes, and structure your tests around user journeys.
So for example, a test for invalid login to Netflix should look like this
I.goTo("https://www.netflix.com/");
I.click("Sign In");
I.fill("Email", "hello@dev.to");
I.fill("Password", "password");
I.click("Sign in");
I.see("Sorry, we can't find an account with this email address.");
And test both the desktop and mobile view like this:
It does get a bit tricky to automate E2E testing for front end because what happens if there's things on the page that are similar? Like many "Add To Cart" buttons for example. Usually people resort to using CSS selectors and XPATHs, but that makes the tests unreadable and hard to maintain. We write our tests like this to solve the problem:
I.goTo("https://redmart.com") // our local online grocer
I.click("Beer, Wine & Spirits") // let's get some beer for a soccer party
I.see("Tiger Lager Beer - 30 x 330ml Case")
I.click("Add to cart") // add that Tiger Beer to the cart
I.see("Heineken Lager Beer - Case") // yea, baby
I.click("Add to cart") // now, get me some Heineken too
If you squint, you can see that the "Add to cart" buttons for each beers changed to "-1+" after being clicked.
Tada! And that's how TDD-ing front-end development can be done.
You can only automate front-end testing so much. This looks like it would save a lot of time, but there's still some level of "does it look right". You still need human judgment in the loop.
Mmhm, you do, you still need human eyes to check if buttons are in the right place - especially in Safari... We try to automate not all, but as much as we can, so things are a little saner. If a machine can do regressions tests massively in parallel, that means we can clear our pre-flight checklist in minutes instead of hours.
Yea let's TDD front-end, baby!
Front-end testing can overwhelming very quickly with so many browsers and resolutions to test. And the permutations of states your UI can be in depending on the ifs and the elses of possible user actions can go up pretty fast too.
Manually testing the UI is time-consuming, and pretty damn boring too. And if you are like me when you are bored, you'd be testing with half-a-brain and very likely to miss a bug.
You should save yourself now, please automate testing.
Just so you know, I'm one of the creators of UI-licious, which is a UI test automation solution, so I'm obviously a strong advocate for automating tests on the front-end. But for good reasons - had my own horrors on software testing.
Anyway, over here at UI-licious, everyone tests. I mean everyone. No, it's not your dedicated QA's job to do ALL the testing. Everyone's responsible for making sure they do their work well, and not leave it to others to deal with crap - especially not the users or customers.
To TDD front-end development, create your UI mockups/wireframes, and structure your tests around user journeys.
So for example, a test for invalid login to Netflix should look like this
And test both the desktop and mobile view like this:
It does get a bit tricky to automate E2E testing for front end because what happens if there's things on the page that are similar? Like many "Add To Cart" buttons for example. Usually people resort to using CSS selectors and XPATHs, but that makes the tests unreadable and hard to maintain. We write our tests like this to solve the problem:
If you squint, you can see that the "Add to cart" buttons for each beers changed to "-1+" after being clicked.
Tada! And that's how TDD-ing front-end development can be done.
You can only automate front-end testing so much. This looks like it would save a lot of time, but there's still some level of "does it look right". You still need human judgment in the loop.
DOM snapshot testing can answer the "does it look same" question efficiently, so that you know where to look to see if it now looks better or worse.
Mmhm, you do, you still need human eyes to check if buttons are in the right place - especially in Safari... We try to automate not all, but as much as we can, so things are a little saner. If a machine can do regressions tests massively in parallel, that means we can clear our pre-flight checklist in minutes instead of hours.
Makes total sense, yeah. I suspect there are some things that human eye does that can be automated too, at least partially.
E.g. "is this thing I just clicked on actually visible" seems like a thing one could check automatically.