I am working on a Rails + React application and investigating frontend testing. Unlike the backend tests this doesn't seem to be a straightforward process with one obvious path. There are a list of possible ways to go about this and they all seem to test in very different ways.

The methods I have found are:

  • Importing the js files and running the functions inside and checking the return values. This seems like the simplest thing to do but very little of our js code simply takes values in and returns something so not much of the app could be tested this way

  • Using libraries like enzyme to simulate the react components rendering and simulating interaction. Also includes storing mocked responses that the server would send to load them in to the test

  • Running the entire backend and frontend and browser using something like selenium and automating the process of actually using the app in a real environment

I'm not very familiar with these libraries so its hard to tell where their limitations and strengths are but I have a list of requirements and example scenarios for what the tests should help with

These examples are:

  • Updating libraries like react/jquery and seeing if anything in the app broke. Selenium would probably work for this but I don't think the emulated component render libraries will because I don't think they actually import all the libraries like jquery when running a test

  • Updating an element and seeing if all the features of that element still work.

Most of the frontend bugs I have encountered result in something not working properly when you interact with it like a button not performing a function it should because jquery was updated. I can't see how anything but selenium could catch this. Are there other options I should be considering or more info about the ones I have listed that would make them do what I need?

2 Answers 2


It depends on what you are testing for... A Website is itself an application that executes on the Browser platform family. So testing an application...

Static Analysers can reveal brittle, broken, badly written, security and other issues across a range of files such as: html, css, and js. These issues are usually low hanging fruit, and very apparent to anyone looking, but take a lot of the work out of checking and help manage just about any-sized code base that isn't trivial.

Unit Tests are best suited for testing logic which is fast to execute, and repeatable that can easily be isolated, and specified. In a website these are usually its javascript files. Something like qunit can allow such logic to be quickly verified, in a surprisingly portable way.

Module/Module Integration Tests are best suited for ensuring the a Module is internally well configured, or ensuring that several modules are correctly configured to co-operate well. Enzyme in this case provides a reference environment that reduces the focus on the html, or specific rendering etc of a given browser. This allows the test to be a little faster, but more importantly when a test fails it eliminates possible causes of failure. If the static analyse and unit test have eliminated issue with the functions themselves that leaves the configuration of those functions/etc as the prime culprit.

End to End (E2E), or Full system tests are best suited for exercising the platform specifics for cross-platform applications, verifying software configuration and deployment, validating long-term life-cycling and operations, and proving key business functionality. They are also the slowest, most brittle, and most expensive tests to have. When one of these tests fails, literally anything could have been the cause, unless Module/Unit/Static Analyses have eliminated possibilities. However these are the only tests capable of demonstrating that a feature works. These tests would be those driven by Selenium and some combination of browsers.

Which kinds of testing, how much, where and when will always depend on the application, and what your test strategy is.

I would at least have E2E tests describing the core business use cases, but when they (or manual testing) reveals an issue, I would explore the problem, and write the fastest test on the least amount of code possible, in the right environment to highlight that issue, and show that it has been fixed.


My experience is with testing React Native. I have had a lot of success using the tools I am listing. I have experimented with Selenium Grid as well. I would recommend using:

Unit Testing


and E2E


I believe these tools are also available for use within React.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.