Data Details for This Category
Data for this category originates from unit and component test code in code repositories, coverage reports generated by test frameworks, interface definitions in requirement documents, and accompanying test cases, Mock specifications, and defect tickets. Data is generated daily or after each code commit by test engineers or automated scripts. Data fields include test case ID, coverage scope, Mock configuration items, defect status and repair records. No unified fixed units apply; values adjust based on specific test scenarios. Overall data volume fluctuates with project scale and code commit frequency.
Constraints for Database and Operations Workflows
This category of data has a high update frequency that fluctuates with code commits. Database connection pools must adapt to sudden read/write requests to avoid connection exhaustion that blocks test builds. Multiple data sources require differentiated read/write permissions to isolate test data from production business data, preventing test configurations or defect data from contaminating production environments. Index associated data for test cases and defect tickets to improve query efficiency when locating failed test cases. Additionally, regularly clean expired test report data to avoid redundant storage resource usage.
Configuration Guidelines
This configuration applies to FastGPT v4.17.0
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
MONGODB_URI | mongodb://fastgpt-test:test-pass@mongodb-test-host:27017/fastgpt-test-db?authSource=admin | Used to store unit test reports, Mock configurations, and defect ticket data. Requires a dedicated test database and authenticated user to isolate from production environments |
PG_URL | postgresql://test-user:test-pass@pg-test-host:5432/fastgpt-test-meta | Stores structured test case metadata and coverage statistics. Uses PostgreSQL to ensure associated query performance |
DB_MAX_LINK | 100–150 | Adapts to concurrent read/write requests from hundreds of daily code commits, prevents connection exhaustion that blocks test builds |
REDIS_URL | redis://redis-test-host:6379/1 | Caches frequently queried test case IDs and coverage statistics to reduce database read/write pressure |
Three Common Configuration Mistakes
- MongoDB connection timeout occurs during local development environment deployment, with the pnpm dev command displaying a connection timeout. The cause is an incorrectly configured host address and port for
MONGODB_URI, or the test database is not running. - Calling MySQL database tools returns a 400 status code with no response body. The cause is incorrectly configured database connection parameters, or the database user does not have read/write permissions for the test scenario.
- Unable to add a dedicated test user to MongoDB and log in normally. The cause is use of an incorrect MongoDB user creation command, or an incorrectly specified authentication database.
How to Verify Successful Configuration
- Run local test commands, and check if the console output displays logs indicating a successful database connection.
- Submit a test code change, and check if the test framework can normally generate coverage reports and write them to the corresponding database.
- Log in to MongoDB or PostgreSQL using the specified database user, and verify that test case and defect ticket data can be read.
- Check Redis cache monitoring metrics, and confirm that frequently queried test data is correctly cached.
All provided values are common starting points, and should be evaluated against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.