Testing Test Writing

Write minimal, strategic tests focused on core user flows and critical paths during feature development, testing behavior over implementation, using clear descriptive names, mocking external dependencies, and keeping tests fast. Use this skill when writing unit tests for functions, classes, or modules in test files (.test.ts, .test.js, .spec.ts, _test.go, test_*.py), creating integration tests that verify multiple components work together correctly (API tests, database integration tests, tRPC procedure tests), writing end-to-end tests for critical user workflows using Playwright, Cypress, or Selenium, deciding what to test and when during development based on risk and criticality, creating test files in directories like tests/, __tests__/, spec/, test/, or colocated with source files, ensuring test coverage for primary user flows and business-critical functionality, or setting up test infrastructure including test databases, fixtures, factories, and mocks. Use this when writing minimal, strategic tests during development instead of testing every change or intermediate implementation step to maintain development velocity while ensuring critical functionality is covered, focusing on completing feature implementation first and then adding tests only at logical completion points (when a feature is working end-to-end) rather than continuously writing tests during development which slows iteration, writing tests exclusively for critical paths (signup, login, checkout, data export), core user flows (creating a project, inviting team members, generating reports), and primary workflows that represent the main value proposition while skipping tests for non-critical utility functions (string formatting, simple getters) and secondary workflows that aren't business-critical, deferring edge case testing (unusual inputs, boundary conditions), error state testing (network failures, validation errors), and extensive validation logic testing unless they are business-critical (like payment processing validation) or part of core functionality to avoid over-testing low-risk code, focusing tests on what the code does (behavior and outcomes like "user can successfully checkout" or "invoice PDF contains all line items") rather than how it does it (implementation details like "calls calculateTax function") to reduce test brittleness when refactoring internal implementation while keeping the same external behavior, using clear, descriptive test names following the pattern "should [expected behavior] when [condition]" that explain what is being tested and the expected outcome (like "should return 404 when user not found" or "should calculate total with tax correctly" or "should send welcome email after signup") making tests self-documenting, mocking external dependencies like databases, third-party APIs (Stripe, SendGrid), file systems, network requests, and other external services using tools like MSW, Vitest mocks, Jest mocks, or test doubles to isolate the unit being tested, improve test reliability by removing external dependencies that can fail or be slow, and speed up test execution, keeping unit tests fast by ensuring they execute in milliseconds (not seconds) without touching databases, file systems, or networks so developers run them frequently during development without friction or context switching, working with test frameworks and tools like Vitest (modern fast test runner), Jest (popular JavaScript testing), React Testing Library (component testing), Playwright (E2E testing), Supertest (API testing), pytest (Python testing), RSpec (Ruby testing), JUnit (Java testing), or similar testing tools following their best practices and conventions, avoiding over-testing of trivial getter/setter methods, simple utility functions that are just wrappers around libraries, or code that provides little business value to avoid wasting time on tests that don't catch meaningful bugs, testing at the appropriate level using the Testing Trophy philosophy: unit tests for pure business logic functions, integration tests for API endpoints and database operations testing multiple components together, and end-to-end tests for complete critical user journeys testing the full stack including UI interactions, ensuring tests are maintainable and easy to understand for the development team by using clear naming, avoiding complex test setup, keeping tests focused on one thing, and using test helpers or factories to reduce duplication in test setup, using test fixtures or factory functions (like createTestUser, createTestOrganization) to generate consistent test data and reduce duplication in test setup code, organizing tests with describe/context blocks that group related tests and provide hierarchical structure making test output easier to understand, testing both happy paths (successful scenarios) and sad paths (error scenarios) for critical functionality but focusing more on happy paths for less critical code, using assertions that clearly express intent like toEqual, toContain, toThrow, toHaveBeenCalledWith rather than complex custom matchers, and ensuring test isolation where each test can run independently without depending on other tests or shared mutable state that can cause flaky tests.