linnene Project Testing Framework Development and Standardization Guidelines
1. Top-Level Design: Multi-Dimensional Test Analysis
Before writing any test code, the testing dimensions must be clearly defined based on the project architecture. Blindly starting to code is prohibited. You must define the priority of the following dimensions based on project characteristics, and all test items must be labeled with a priority level:
- Blocker (P0): Core business main paths, critical logic affecting system stability, and operations involving data consistency. If a P0 test fails, merging code or releasing versions is strictly prohibited.
- Critical (P1): Main functional modules and standard exception handling. Failures must be fixed within a specific timeframe.
- Normal (P2): Secondary functions, optimization validation of boundary conditions, and non-core UI or interactions.
Based on the above levels, the following testing dimensions must be covered:
- Unit Testing: Targets the smallest logical units (e.g., utility functions, algorithm logic), requiring 100% logic coverage.
- Integration Testing: Validates interactions between modules (e.g., database access, cache read/write, message queues).
- Scenario / End-to-End (E2E) Testing: Simulates complete user paths to validate core business logic.
- Non-functional Testing: Includes performance/stress testing (response under high concurrency) and robustness testing (fault injection, timeout handling).
2. Initialization Process: Structure First and Granularity Control
Writing specific implementations right away is prohibited. The construction of the testing framework must follow the "skeleton synchronization" principle:
- Directory Mapping: The test directory structure must strictly mirror the source code directory structure.
- Function Declaration: First, create test files and complete the declarations of all test functions. Writing logic before defining granularity is prohibited.
- Granularity and Redundancy Elimination: A single test function must only verify one specific scenario. Cross-logic should be resolved using Mocking or Setup/Teardown mechanisms to avoid redundantly verifying the internal logic of Module B within the tests for Module A.
3. File-Level Documentation Standards
The top description block of each test file must indicate its position within the overall architecture and its highest priority level.
Standard Format:
"""
Description: [Module Name] Test Suite
Mapping: Maps to source code file /src/service/order_service.go
Priority: P0 - Core transaction logic
Main Test Items:
1. Idempotency of order creation (P0)
2. Stacked coupon calculation (P1)
3. Pagination logic for historical order display (P2)
"""
4. Function-Level Documentation and Assertion Standards
Each test function must not only explain its responsibility but also adhere to a strong-feedback assertion protocol.
4.1 Description Standards
"""
Priority: P0
Description: Verifies the atomicity of order inventory deduction under high concurrency.
Responsibility: Prevents overselling and ensures database transactions rollback correctly.
Assertion Standard: Remaining inventory must equal (original inventory - successful orders).
"""
4.2 Assertion Feedback Standards Using semantically meaningless simple equality assertions is prohibited. When an assertion fails, detailed context information must be output to facilitate quick troubleshooting.
- Required Content: Input parameters, expected results, actual results, specific state at the location where the error was triggered, and an assessment of the impact on system stability.
5. Dynamic Maintenance Document: TEST_MANIFEST.md
A test manifest document must be maintained in the root directory of the test folder to record the specific status of the current project's testing framework.
A. Coverage and Dimension Matrix Use a list or table to display the currently covered testing dimensions, corresponding files, and the quantity of P0/P1 items.
B. Detailed Test Item Table List the specific test items in each test file, along with their priority, focus areas, assertion standards, or effectiveness evaluation criteria.
C. Deep Dive into Core / High-Risk Items For critical test items that directly impact system stability, you must document the following in detail:
- Input: Specific boundary values, invalid character sets, or high-concurrency request volumes.
- Output Assertion: Specific expected results and system states (e.g., log records, database snapshots).
- Failure Impact and Evaluation Standards: How failing to test or failing the test would significantly impact system stability (e.g., memory leaks, deadlocks). For fuzzy matching or performance-based tests, define clear target scores or latency limits.