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.
Oldest comments (41)
Yes. For various reasons we actually have more FE unit tests than BE unit tests. The aim is to have reasonable coverage for both. They're supported by end-to-end API tests (they cover a lot of transactional logic and system integration that unit tests can't cover) and a small number of end-to-end UI tests.
With great difficulty! There are unit tests for the client FE code - which are relatively painless and standard, but these change a lot depending on the frameworks adopted. The last project I was working on was an Angular based web app, the next is likely to be a React based web app - each comes with its own testing framework.
But we do try and use Protractor to do some browser testing for our Front End as well as running End to End testing, however, browser versions were the undoing! We spent a lot of time updating the end to end tests/component tests to work with the latest browser versions. Sometimes it was as simple of upgrading Protractor, others involved some refactoring - but it does add overhead!
I was just discussing with a colleague this morning the plethora of front end testing frameworks there are: Jasmine, Jest, Mocha, Chai the list goes on! (And sometimes you might use a combination of them!)
Something that has worked well for us is that we have used Cucumber/Gherkin for our component and End To End testing. This has meant that there was a common language of testing regardless of the language/frameworks adopted for the actual components. Something I would definitely recommend to others to consider.
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.
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.)
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:
Yeah, we use Create React App which has Jest configured. Right now we are sitting around 250 tests. We shoot for 85% coverage overall with 100% coverage of core logic like state and reducers.
No, but we use Selenium to take screenshots in a production site, so that's something.
I know that, with tools like Selenium, that is doable. But I do not.
Yes. We write E2E tests because it is the easiest way to verify Front and Backend work together. For web applications it is nowadays really easy todo.
If you have PHP in your stack Checkout codeception. There is a Chrome Extension where you can literally click together your test cases.
We have the unit tests for our Vue app and end to end tests (selenium) that does all the interaction through our app, so I guess the answer is yes.
Yes! I try to push for very high levels of coverage on state management, state selectors, etc. Unit testing in this manner is a really good sense of security and lets us refactor without fear. Component testing is a little more lax, but the core functions must still testable - make sure things mount, spy on dispatchers to see that they're called when you simulate clicks, etc.
It's well worth writing at least functional tests for frontend code so that you can refactor easier should you find in the future that you have some code smell.
For interviewing people, you can often find confusion about simple things in the online interview. I've recently switched to presenting frontend candidates with a CoderPad, pre-populated with an empty function and a test suite against what it should do. This highlights unit tests abilities to serve as documentation - you can easily write tests against the functional requirements of a system. Since doing so, candidates have had an easier time understanding what should happen, even with a language barrier.
No, we don't. But we are probably updating our front end soon, I'm not sure if we are going to add tests. The js tooling is a nightmare right now D:
If I could find an agnostic service for reliable front-end integration testing, I would do more of it. Especially one that could be used on static sites.
Yes.
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).
We use Ember and write a lot of tests for that to make sure that front-end behavior is working how it's supposed to. Right now we use Ember QUnit which works pretty well for most cases in Ember, especially since they recently unified their testing api to be easier to use and understand.
Yes, started writing extensive test for front end when our team started using react. It helps if the framework you are using has good libraries to support testing. From what I have used react has enzyme and vue has vue test utils.
It can be tedious in the beginning, and can increase feature delivery time, but over the long run very beneficial. And of course it makes development FUN.
Hi, I m kind of assuming you also use redux.
If so, what s the strategy you guys adopted to test connected components (redux)?
Do you test the component with or without a mock provider?
Thanks!