# Fastdeploy unit test guide - FastDeploy: Large Language Model Deployment

Skip to content

简体中文

# FastDeploy Unit Test Specification

1. Test Naming Conventions
2. Test files must start with test_.

3. Test methods are recommended to follow the format test_func_behavior or test_func for clarity and readability.

4. Directory Structure

5. All unit tests should be placed under the test/ directory and organized into subdirectories following the FastDeploy module structure for easier maintenance and navigation.Reference: vllm

6. Coverage Scope,Each key module/class/function must be covered, including:

7. Normal Path: Standard input and main workflow.

8. Boundary Input: Empty values, extremely large/small values, and boundary conditions.

9. Abnormal Input: Invalid parameters, incorrect formats, etc. Ensure that exception handling matches expectations (e.g., check exception content).

10. Case Writing & Execution

11. Test cases should support one-click execution in both CI and local environments via pytest or unittest.

12. Use explicit assert statements to validate module behavior or return values; avoid relying solely on printed outputs.
13. Each test case should maintain strong atomicity, focusing on a single behavior and avoiding mixing multiple functions in one test.
14. Tests must be independent of execution order and global state, ensuring complete decoupling between cases.

15. Custom operators must have C++-level unit tests, or forward/backward tests based on Paddle single-layer networks. Refer to Xiaoguang’s documentation on custom operator development toolkit and non-official operator development specification (trial).

16. WebServer-related Tests

17. Avoid starting a WebServer directly in unit tests unless absolutely necessary for end-to-end validation.

18. Prefer using mock for network requests and module interactions to achieve more stable and controllable atomic-level testing.
19. If HTTP requests must be tested:
20. QA will provide a port injection specification (ports are written into environment variables, which test cases can directly load). This spec and scripts are expected to be ready by next Wednesday.
21. Test cases should read ports from environment variables instead of hardcoding them, ensuring reusability in CI multi-instance concurrency and easier local debugging.