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.