unit-testinglisted

# Unit Testing Write and run fast, isolated tests for individual functions, methods, classes, or modules. Unit tests verify correctness at the smallest useful boundary without external services, networks, or UI. ## When to write - **New code**: write a failing unit test before implementation (test-first), then implement the smallest change to make it pass. - **Bug fix**: write a focused regression unit test that reproduces the bug, confirm it fails, apply the fix, confirm it passes. - **Changed logic**: update or add unit tests when existing behavior changes. ## What to test - Core logic: calculations, transformations, validations, state transitions. - Edge cases: empty input, null/undefined, boundary values, maximum/minimum, off-by-one. - Error handling: invalid input, missing fields, permission denial, timeout simulation. - Branch coverage: every meaningful if/else, switch case, try/catch path. - Pure functions first: they are the easiest to unit test and give the highest confidence per effort. ## What not to test - Framework boilerplate or trivial getters/setters. - Third-party library internals (test your integration with them, not their implementation). - Implementation details that do not affect observable behavior. ## How to write - Follow the project's existing test framework, file naming, and directory conventions. - Each test should be independent and runnable in isolation. - Use descriptive test names that state the scenario and expected outcome. - Prefer