Testing Coverage Philosophy - A Discussion and Overview of Objectives

[mikhael28]

Right now, our test coverage is nearly non-existent. This is a problem, as manual testing of every pull-request ultimately creates a bottleneck for maintainers to approve code and keep things moving. This ticket is somewhat of a discussion about what our testing strategy should be, and how to keep things practical at first - and then, at some point, opening the floodgates for people to write ridiculously granular test coverage of components that don't need it.

My first thinking is to focus on writing some foundational headless browser tests through Cypress, mounting the application, fetching data through a real user account's ID, and then bouncing from route to route - checking to see if anything is obviously broken.

From there, we can expand the navigational tests to individual components, then to interactions through the actual application. Then, we can perhaps do some snapshot testing, to watch for excessively major UI changes.

From my perspective, while integration and navigational testing is very valuable, I've never quite understood the need for unit testing in modern JavaScript for UI components - can someone enlighten me and give me some new perspectives?

I would also like to hear feedback from the community in general about your thoughts on practical testing strategies (to start with) for open-source projects like this.

[akashshyamdev]

I think this is great and we must move on with e2e testing. Also, here's why unit testing matters:

Unit testing addresses minor things(surprise surprise!) like proper form validation, form state etc. Now this may not seem important on an individual basis, but let's say I come and refactor a logic into a function. We can have a bot that checks for the unit tests on that specific component and informs the author of the PR about the issues. Such things are usually implemented in large code bases.

It may seem like a huge task, but will save both the reviewer and the author of the PR a lot of time(instead of waiting for the reviewer to catch a bug and then solving). Of course doing this in one shot is a huge task, and would take a lot of time. I think you should create issues for each component with a label of "good first issue" to encourage new contributors(similar to what you did with conversion to hooks).

Looking forward to your reply @mikhael28!

[mikhael28]

Yes @akashshyamdev that is a good strategy, I should break down the process into smaller issues that will allow new contributors to send in PR's. I think, similar to slowly adding in propTypes, we can add tests in on a component by component basis as well. Perhaps, when someone touches up a component, we can have them add a test or two (if it makes sense).

[mikhael28]

For the record, I think a lot of unit tests (for forms, at least) are rendered unnecessary by having good form validation set up. Migrating to React-Hook-Forms at some point is high on our list, as it get's us closer to getting out from under the boot of react-bootstrap 0.32.