testinglisted

# Testing ## What to Test Test behavior, not implementation. A test should verify what a function does, not how it does it. If you refactor the internals and the test breaks, the test was testing the wrong thing. Good test: "given a valid email, returns true" Bad test: "calls regex.match with pattern /^[a-z].../" ## Meaningful Coverage vs Line Coverage 100% line coverage is a vanity metric. You can have 100% coverage and still ship bugs if your tests don't exercise meaningful paths. Focus coverage on: - Business logic (the rules that make your app unique) - Error handling paths (what happens when things go wrong) - Boundary conditions (empty, null, max values, off-by-one) - Integration points (where your code meets external systems) Skip coverage on: - Simple getters/setters - Framework boilerplate - Generated code - Pure delegation (functions that just call another function) ## Edge Cases Worth Testing Every function has these potential edge cases. Consider which apply: - Null / undefined / empty string - Empty array / empty object - Single element - Very large input - Negative numbers / zero - Unicode and special characters - Concurrent access - Network timeout / failure You don't need to test ALL of these for every function. Think about which ones are realistic for your specific case. ## Test-First Workflow Writing tests first helps when: - The behavior is well-defined but the implementation isn't clear - You're fixing a bug (write the failing test first, t