What the data for this category looks like
Business data for unit testing and component testing originates from code repositories, test framework reports, requirement specifications, and interface definitions. The update rhythm is daily or after each code commit. Daily produced documents include test cases, coverage reports, Mock instructions, and defect tickets. Test cases contain case identifiers, preconditions, execution steps, and expected results. Mock instructions contain dependent service addresses and return parameter templates. Defect tickets contain reproduction steps, log snippets, and associated code line numbers. Some statistical documents use lines of code and percentage as units. Other documents have no mandatory unified field format.
What constraints do these characteristics impose on the context and token link
Dispersed data sources and high update frequency require context to synchronize the latest test cases, coverage reports and other content in a timely manner, to avoid using expired Mock instructions or defect tickets. Diverse document formats and association with specific code modules require context to accurately match the test data of the corresponding component, preventing invalid cross-module content from being mixed in and causing token waste. Large differences in token usage per single document: long coverage reports and complex Mock instructions may occupy more tokens. This requires context to limit the length of a single reference, avoiding the overall context exceeding the model's upper limit.
How to set the configuration
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
maxContext | 10000–16000 token | Matches the total token scale of unit testing and component testing documents, preventing the model from truncating key test cases and dependency instructions |
quoteMaxToken | 1200–2000 token | Adapts to the average length of a single test case or Mock instruction, ensuring that a single referenced piece of content is complete and does not occupy excessive context space |
| Context synchronization frequency | After each code commit | Matches the feature that data updates occur per commit or daily, ensuring that context always uses the latest test data |
| Context recall limit | Top 4–6 entries | Aligns with the module relevance of test documents, avoiding recalling too many irrelevant coverage reports or historical defect tickets |
Three common misconfigurations
- The number of context entries displayed in the interface does not match the actual number of referenced entries. For example, the interface only displays 30 context entries, but more than 300 documents are referenced in the actual request. The cause is that the
maxContextparameter is not configured correctly. The system only retains a small preset number of context entries, and does not include all recalled valid documents in the request scope. - The calculated token usage of the knowledge base does not match the actual consumption. The cause is that token calculation is not performed separately for code snippets and comment content in test documents, and only estimated based on plain text length, resulting in actual token usage exceeding expectations.
- Custom context cannot be passed via API parameters, and only the system's default spliced historical records can be used. The cause is that the corresponding switch for custom context passing in FastGPT v4.17.0 is not enabled, causing the API to fail to receive externally passed context content.
How to confirm the configuration is complete
- Check the update log of the currently bound test document library, confirm that test cases and coverage reports after the most recent code commit have been synchronized to the context pool.
- Initiate a test case drafting request, check that the number of context documents referenced in the returned result conforms to the configured recall limit.
- Check the token usage log of the request, confirm that the total token of a single request does not exceed the set value of
maxContext. - Try to pass custom test case context content via the API, confirm that the request succeeds and the custom content is correctly applied to the document drafting process.
The values provided are common starting points and should be measured 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.