Applicable Scenarios
- Writing unit tests for Service / DAO / utility classes
- Mocking external dependencies and boundary conditions
- Verifying happy paths, failure paths, and regression scenarios
- Adopting TDD or adding tests to prevent regressions
Inapplicable Scenarios
- Integration testing, end-to-end testing
- Only implementing business logic, with no plan to add tests
- Only troubleshooting runtime environment issues
Quick Guide
- This skill focuses on how to write unit tests in the BK-CI project, not a general overview of testing theory.
- Tests should first ensure clear intent, then consider coverage; the focus is on critical branches and regression risks.
- Common patterns are still AAA, mocking external dependencies, and explicitly asserting results and interactions.
- Before writing tests, first confirm that you are testing business rules, not mechanically restating implementation details.
- If the test involves backend interfaces or service structure, then also look at
backend-microservice-development。
High-Signal Rules
- Both happy paths and failure paths should have representative coverage
- Mocking should serve to isolate boundaries, not to mask design problems
- Test naming should directly express behavior and expectations
Key Pitfalls
- Testing only the happy path
- Over-mocking, causing tests to lose almost all behavioral value
- Assertions that are too weak, only proving the code ran, not proving the result is correct
Further Reading
- If you are modifying a backend service: also look at
backend-microservice-development