DEV Community

Ben Halpern
Ben Halpern

Posted on

Does your team write code tests for front-end code?

This is a question from the State of the Web Survey we just put out today, but I thought this would make for a good discussion question.

In web-land it definitely seems more common to test back-end code than front-end. This is probably changing as tooling gets better, but I was wondering what your thoughts on the issue were.

Top comments (42)

david_j_eddy profile image
David J Eddy

My most recent web team did write front end (FE) tests. Unit for JS logic and user acceptance story style tests using Jest and Puppeteer. We even ended up making a Docker Image to run the tests in a headless manner.

Unit tests were reasonable easy to write in Jest. I am historically a backend dev. but was able to write some Jest unti tests with little frustration.

The process to take user stories from product/project owners and convert them to Jest logic was fairly straight forward for the type of stories we had. Leveraging the Docker image we were able to execute the tests via Jenkins as part of our continuous deployment process.

Docker + Jest + Puppeteer (Headless Chrome) :

shiling profile image
Shi Ling • Edited



Anything that can go wrong will go wrong. - Murphey's law

  • Front-end code changes more frequently than any other piece of code. You are probably going to introduce more bugs on the UI than anywhere else.
  • It's madness to test the UI on every single browser / OS / device by hand.
  • Testing the app by hand is primitive and mind-numbingly boring. You can actually make mistakes testing because you are brain-dead / half-asleep.

Everyone in my team writes UI tests, partly because we built UI-licious, a tool to automate UI testing for web apps.

The problem with front-end testing...

Is that with the way the testing tools work today, tests are wired to the actual design and implementation of the UI, and quickly become obsolete.

This means that you need to create multiple tests to test desktop and mobile designs for the same test scenario. And whenever the design or code is changed, the tests needs to be updated. It's a colossal waste of time to be going back and forth to fix broken tests.

Plus the use of CSS selectors, XPATHs and magic waits make the test horribly unreadable and difficult to maintain.

Tests should be independent from implementation because it is supposed to test if the implementation follows the specs. It makes no sense at all for tests to be wired to implementation. And why does it even matter what front-end framework - Angular/React/VueJS you use?

What then, does specs mean for the front-end then? The user's journey. That's how your app deliver's value to the consumers.

That's why I ended up creating UI-licious, because:

  • it should be possible to write a test once and run it against any desktop/mobile/present/future UI design, built with any front-end framework,
  • it should be possible to TDD front-end development, and
  • it should be possible to test of your app works for any user - people with and without accessible needs.

The UI-licious test engine does the heavy lifting of deciding how to correctly interact with any UI given simple commands, even in ambiguous scenarios where multiple elements are similar. Under the hood, there's some dynamic code analysis and good old-school AI involved to do this.

In any case, front-end code is still code, it changes, it has smells, it has bugs. Is there a good reason not to test it besides the lack of good tools to do so?

manuelbarzi profile image
manuelbarzi • Edited

If the "CORE THING" of an application is well tested, and with that I mean the most important part: The Business Layer (and its inner Data Layer). Then focussing on testing the upper layers (UI, Front, UI Components...) is for sure good. But only to be relevant once FIRST the inner layers are widely tested (Business and Data).

And this implies front-end and back-end. If you are following a proper architecture, for instance, in a client-server projection for an SPA consuming an API, where you have created an abstraction of your Business Layer in both the client and the server sides, following a correct Separation of Concerns, and isolated, then that should be the initial target to test.

[Front-end] -> [Logic (business)] -> [API clients] ··· (XHR / HTTP) ···> [Back-end] -> [Logic (business)] -> [Data]

And once having fully assured those Logic (business) components are fully tested, then proceed to bring effort on pure UI / Front / Components testing.

This principle also follows the way of thinking of the Test Pyramid, in which not only deciding which parts of a software should be tested first is important, but what's the effort and COST on them. For sure, testing the inner-lower layers (Business, Data) requires a lot of coding, but in general is much more faster and secure to first being compliance with that, and later on with the upper layers.

Here's also a good article that concerns on this: The Practical Test Pyramid

jfrankcarr profile image
Frank Carr


Exactly how depends on the application. Web apps are tested using Selenium right now but our testing team is evaluating some other, more comprehensive, apps. One of the criteria we have for a new testing tool is one that will perform well with web and desktop apps

Our desktop apps don't currently have automated tests but we have a documented test plan for the testing team to follow. This gets to be a bit tricky since to do complete tests, we have to have do them on a manufacturing line that has all the devices operational (barcode readers, lasers, PLCs, etc).

kspeakman profile image
Kasey Speakman • Edited

Not at present.

I can think of some things that it would be good to test. For example, user-entered data producing the appropriate results.

But when I think of bugs we fixed so far (Elm app), writing tests would not have caught most of them up front. They were fundamentally because two pages or controls inappropriately shared state -- either squashing the other's changes or leaving a mess the other wasn't expecting. But initial tests would have been for each thing in isolation and so would not have caught it. Testing all permutations is not really feasible due to finite resources such as money and human lifespans.

Our general policy when these bugs crop up is to separate concerns and, where possible, make the illegal state unrepresentable. This can entail some restructuring of the UI model. It takes perhaps longer than writing a test for the failure and patching in defensive code. But it prevents regressions as well as improving the flow and organization of the code. It is not too terrible to do in Elm as the compiler is great at telling you when you structurally break things.

scott_yeatts profile image
Scott Yeatts

Yes, and I'm amazed that this is even something anyone would think to ask in 2018 (No offense Ben).

Some people say that front-end unit testing won't catch bugs... and it won't. Not for new development anyway, just like if you don't write tests for edge cases you don't know about in the back-end it won't catch those either. The beauty of a robust and comprehensive testing platform isn't that it catches the bug in the story you're working on TODAY (Although it WILL and you won't think about it because you expect those tests to fail until you're done building). It will catch the bug in the story 6 months from now when a completely different developer has no idea what you did and changes something important to this functionality.

This is why there are so many people who argue AGAINST unit testing. They don't understand WHY you do it. It's just one part of the trifecta of tested, modular and separated concerns. It keeps your app stable. You do all three, and you might never see a broken unit test... not because they're useless, but because you built the thing well (and yes you can have modular code with poor separation of concerns... It will make you want to cry).

Our unit test coverage is actually (much) higher in the front-end than back-end right now, and we have both Protractor and Selenium integration and E2E tests. For almost a decade front-end applications have had just as much application logic that can be easily unit tested as any back-end service. We basically just treat it like any other microservice, but with quirks. A team thinking that they don't need to test the front-end tells me that either they have a very simple front-end (so how complex could the back-end be?) or they are stuck in 2005 with a 'just the front-end' bias.

Neither is a great sign for a modern web application, leaves a TON of logic untested and is going to fail to draw top talent your way. All of that from a simple interview question 'Do you do front-end testing?'.

eerk profile image
eerk • Edited

I found that using Typescript instead of Javascript introduces lots of ways to reduce the need for unit testing on frontend JS logic. Especially unit tests that check what goes into a function and what comes out, can be replaced with defining detailed type information.

It's great to see faults in your code be highlighted while you are typing, instead of having to run all kinds of test processes first.

aodev profile image

This situation can be approached from the possible consequences of failure.

If we talk about the "typical" client app talking to backend services, then usually, front-end is more forgiving than backend is, when a problem arises.

In the end, whatever technology you use in backend, it can have many types of clients, and barely cares about them, whether they are a web app, a native mobile app, an IOT device, etc...

That said, web front-end, unless a terrible mistake is made, is allowed to fail and continue. Should it be? That's another debate. But the strategy on the web is ship fast, fail fast, fix fast, repeat.

A user can easily survive a misaligned button, an ugly interface, a blue screen of death XD (app crash). Even a temporary "I click but nothing happens".
"Restart the computer, phone, app", "use another browser" are half solutions but quickly done and in the hands of the user. Things can be fixed quickly.

Now, for the backend, a "stupid" mistake can bring the whole business to a halt. Data loss or data corruption, that's one thing you don't want. Security breach isn't better and you don't want a core functionality like "payments" to die on you. If millions of users are affected in an instant, that's a serious reputation risk and a business failure.

These were my thoughts about why backend is more tested, or maybe "should be" more tested.

That said, I am more of a front-end person, and I do want apps to be tested. It's quite easy to write unit-tests nowadays. Especially in case of refactor, having good tests in place can save you a lot of time and from realising too late that the wrong data is displayed. On the other hand, E2E tests for the most crucial user stories will save the day far more than people think.

A last thought that comes to mind: the rise and goal of micro-services in backend is to avoid complete failure. The business can continue by allowing non-critical services to fail. Again, this is designing for failure. Tests should reflect where the risks are. It can happen that the front-end value is far superior to the back-end one. Test accordingly.

itsasine profile image
ItsASine (Kayla)

I've actually heard more people be opinionated that the front-end code is more important to test than back-end code. The idea is that if the back breaks, the front breaks. If the front breaks, the back could still be passing. Front tests breaking will tell you if the front or back is broken, which at least gives a better picture of the application.

My workplace shoots for 70% unit test coverage (yes, coverage is a BS metric... it's a large company) of all code. Front, back, whatever. And every feature gets automated end-to-end tests as well.

My E2E stack is Protractor and Jasmine, since all the front ends at work are Angular. I haven't had any issues with the tooling other than some quirks around how every extra package seems to make it more likely that Protractor is going to have timing or intermittent issues. Vanilla Angular plays fine with it, though, and Jasmine is 👌

itsasine profile image
ItsASine (Kayla)

And by quirks, I mean running supertest tests from the Protractor run, sending MySQL queries during beforeAlls, and other things Protractor totally wasn't meant to do. But also the Angular app having 3rd party libraries which work manually but make Protractor give up.

craser profile image
Chris Raser

We're adding front-end testing slowly and tentatively. We've added facilities for front-end and back-end testing using Jest, and we're starting to play with Cypress for end-to-end testing. The advantage of Cypress is that we can use the same assertion frameworks for all our testing. The downside is a lack of support for testing various browsers/versions. (Selenium has the advantage there.)

the_fln profile image
Francois Lanthier Nadeau

Colleague of mine at Snipcart met a guy doing a presentation on Cypress in a WinnipegJS meetup. Very cool framework (I agree with the mentioned downside though). We ended up collaborating with the guy in question on a post tackling frontend testing w/ Cypress (e2e more specifically). In case it's any help/interest:

 Modern Frontend Testing with Framework

nickytonline profile image
Nick Taylor • Edited

We don't strive for 100% code coverage, but we do have unit tests for all things redux and any other code that is not actual UI.

For UI, we use Storybook to build/test components in isolation (we're a React/TypeScript shop). I consider Storybook to be part of tests as well, even if only visual.

Aside from that, where relevant, snapshot testing. I haven't had time, but Storybook has Storyshots which allows you to incorporate snapshot testing right in Storybook.

When I worked at McAfee on the True Key password manager, E2E testing was crucial as we had to ensure the browser extension worked correctly.

At the moment, where I'm at, we do not have any end to end testing in place. It's something I'm pushing for. I've been looking into Cypress. That's one of the things I'd like to get in place this year.

adambrandizzi profile image
Adam Brandizzi

Here at Liferay, we do test front-end, but that depends on some factors. For example, we have our own JavaScript framework and it is heavily tested (if I'm going to believe my colleagues there 😉). But most of our projects are portal apps, and those are not heavily tested on the front end. Personally, I write as much JavaScript unit tests as possible, and I hope the culture of unit testing for JavaScript flourishes.

Besides that, we have a long rich tradition on using end-to-end tests; indeed, unit and integration tests are a somewhat recent development! In this case, we have a nice XML-based language (POSHI) that uses Selenium under the cover. It is great (we get so many things that we would miss!) but those tests are quite slow. So, JS unit tests are still useful.

simoroshka profile image
Anna Simoroshka

At work - no.
At the hobby project - yes, we are getting into it. Cypress and jest + react-testing-library, both of which I find great. They encourage to test how components or the app behave, not the implementation details. I find it very helpful.

akenverus profile image

What tests exactly?
If unit tests for library, for example - yes. All pure functions are covered with tests.
If component tests (react testing library, karma, jest) - no. In 15 years of development experience I've been convinced that this is just a waste of time.
If e2e tests (Protractor, Cypress, etc.) - it depends. Only to test complex repetitive scenarios.
And if you've been told that some team is always writing tests for the frontend, don't believe it. I've worked in and heard about only couple of teams/companies which are taking time to cover frontend with tests.
Most of the time most of the frontend projects are not covered with tests at all.

stealthmusic profile image
Jan Wedel

Absolutely yes. With typescript and angular, it’s pretty easy to write tests, mock things etc. writing E2E tests is a bit harder but it’s definitely worth it.

As I stated in by article about testing: I always wonder how many people do not write tests. Front is code as well, so why on earth would you not test it? If your code is hard too test, then the code is probably badly designed. That’s a smell and it should be fixed.