This story is unavailable.

Acceptance, E2E tests, yes. Unit tests, no. Arguing against shallow rendering is one thing, but here you’re now arguing against unit tests in general. You will end up with a nightmare in very large apps if you are covering the same code with 100 different tests and something breaks. This becomes apparent after several years of the same codebase growing and growing, but won’t be apparent at with smaller repos. To combat this, the paradigm in Ruby is usually to cover the happy case user story only with E2E tests and then cover edge cases with unit tests. Unit tests are also great for TDD which is not mentioned here (but that can be forgiven since most JS developers don’t do TDD). That’s not to say it’s a decided issue for me; this debate has gone on for decades now in the Java and Ruby communities (see the epic debate between DHH, Beck, and Fowler regarding TDD and unit testing vs. integration/acceptance/e2e testing).