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 (41)
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!
Crawling search engine results and returning highlighted visuals.
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.
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.
No. Goals are to split the monolith, redesign, fix identity management, and then cypress.
On mobile but I can write more on this later if folks are interested. TLDR:
We have an in-house package I created that basically puts data tags on React components, and the QA team writes tests that check for & interact with the page by selecting elements with those data tags.
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.