Jest/Vitest interactive course (runs in the browser)

The strongest consensus was that module-level mocking in Jest and Vitest is dangerously easy to overuse. People called it a code smell because it lets tests replace imports instead of designing code with clearer boundaries, and because it can tie a codebase to a specific test runner. Even people who defended mocks in JavaScript framed them as something that needs guardrails like lint rules and typed helper APIs, not a default move. That fed into a broader critique of frontend unit tests. Several commenters said component-level tests often become expensive to maintain and can pass even when the product is effectively broken, especially when the test suite mocks away too much of reality. The preferred alternative was a stronger end-to-end layer, with Playwright-style tests exercising the app the way users actually do and varying things like locale, timezone, and screen size. The more grounded position was not that unit tests are useless, but that their value depends on what they touch. Tests around parsers, encoders, math-heavy logic, libraries, or business-heavy UI flows with little or no mocking were seen as worthwhile. Tests that are hard to write were also treated as a useful design signal. If a React component is painful to test, that often means the component is too tangled. The discussion landed on a pragmatic hierarchy: keep unit tests for real logic and design feedback, be skeptical of mock-heavy component tests, and invest in reliable end-to-end coverage for the behavior the business actually ships.