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.
Latest comments (42)
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.
We have the unit tests (jest) in our Angular app and some basic e2e tests (selenium webdriver). I am working on Visual Regression Testing (jest & puppeteer) :)
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.
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
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.
We do for the web and, surprisingly, it's not too intrusive / unwieldy although there has been some extra work in refactoring the tests as requirements change. We're using Karma / Jasmine unit testing several Angular sites. Time in CI for unit testing is about 30% of the build (~60% is npm updates).
We do not unit test the front end components for desktop apps used in-house (WPF).
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?'.
I prefer to write Unit tests as well as E2E(Integration or Acceptance) tests for a frontend. Usually, there are a lot of flows which can confuse the user. Unit tests grant stability, so you can be sure that component will work if input data is valid. And E2E allows you to check the whole user flow.
Most complex - is to test interface (CSS) and check if interface corresponds to the design.
Everything should be automated no matter frontend or backend. If it will save your time - automate it.
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.
Absolutely.
Because...
Anything that can go wrong will go wrong. - Murphey's law
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:
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?
Definitely, we do write test. I like selenium , too. I use the awesome extension they have in Firefox dev edition. Testing the FE code is just as important as user exp testing IMHO. Also, I really like using phantom with Angular, Jasmine with Karma as test runner. The output shows up via Jasmine's HTML reporter and that's nice too. Here is a link to a sample run:
stackblitz.com/edit/angular-yxk8rk
and here is a link to the tests:
angular.io/generated/zips/testing/...
This is a screenshot of the selenium extension:
Enjoy!