Test-Driven Development for LLM Applications: Practical Prompt Regression Testing

Introduction: Why Prompt Regression Testing Matters

In traditional software development, regression testing is the core defense for ensuring code quality. However, when it comes to LLM applications, many teams still rely on 'manually trying a few prompts, and if they look okay, ship it.' This approach is extremely risky: LLM behavior is probabilistic, and a small prompt change can cause a cliff-like drop in production answer quality. I've seen a customer service bot where simply changing 'please use a polite tone' to 'please use a friendly tone' led to a 37% increase in complaint rate, and regression testing completely missed it.

The core idea of prompt regression testing is to treat prompts like code: any modification must be validated against a fixed set of test cases to ensure output quality remains within acceptable bounds. This sounds simple, but implementation involves many engineering details, such as how to select test cases, how to define 'quality', how to evaluate output similarity, and how to handle model uncertainty. This article provides a practical path based on hands-on experience with the DeepSeek API.

Step 1: Define Your Test Set - Mine from Real Logs

Many tutorials tell you to 'carefully design 10 test cases,' but this is completely misleading. A real test set should come from actual production inputs, not your imagination. I made this mistake early in a project: I designed some questions I thought were 'tricky,' but after launch, I found that real user questions were not covered, making the tests useless.

The correct approach is: randomly sample 200-500 user inputs from application logs, then use clustering (e.g., embedding similarity) to select 50-100 representative samples. The key here is diversity—covering different lengths, topics, emotions, and language styles. If the application is a classification scenario, ensure each class has sufficient samples. My experience is that test set quality matters more than quantity; 50 well-covered cases are far better than 500 highly repetitive ones.

The table below shows an example test set composition for an e-commerce customer service scenario; you can adjust the proportions based on your business:

Step 2: Write a Test Runner - Batch Evaluation with DeepSeek API

Once the test set is defined, the next step is batch calling the model. Here's an engineering pitfall: don't hardcode API call logic directly in test code; instead, encapsulate it into a reusable test runner. Below is the core part of a Python test runner I used in a project, supporting concurrent calls, timeout handling, and result recording:

import openai, json, concurrent.futures
client = openai.OpenAI(api_key='your-deepseek-api-key', base_url='https://api.deepseek.com')

def run_case(prompt, system_prompt):
    response = client.chat.completions.create(
        model='deepseek-chat',
        messages=[
            {'role': 'system', 'content': system_prompt},
            {'role': 'user', 'content': prompt}
        ],
        temperature=0.3,  # Low temperature recommended for regression testing to improve stability
        max_tokens=500
    )
    return response.choices[0].message.content

def run_test_suite(test_cases, system_prompt):
    results = []
    with concurrent.futures.ThreadPoolExecutor(max_workers=8) as executor:
        futures = {executor.submit(run_case, case['prompt'], system_prompt): case for case in test_cases}
        for future in concurrent.futures.as_completed(futures):
            case = futures[future]
            try:
                output = future.result()
                results.append({'prompt': case['prompt'], 'expected': case.get('expected'), 'actual': output})
            except Exception as e:
                results.append({'prompt': case['prompt'], 'error': str(e)})
    return results

When calling, note: temperature should be set between 0.2 and 0.3, which significantly reduces output randomness and makes test results more reproducible. I tested on the DeepSeek API; lowering temperature from 0.7 to 0.2 reduced output variance for the same test case by about 80%, but be aware that too low a temperature sacrifices some creativity, so the specific value should be balanced based on the scenario.

Another pitfall is concurrency and rate limiting. The DeepSeek API has rate limits (depending on the plan); directly opening 20 threads may trigger 429 errors. I recommend using ThreadPoolExecutor to control concurrency between 5 and 8, and add a simple retry mechanism (wait 1 second and retry on 429 or 5xx). The test runner outputs a JSON result file for easy comparison later.

Step 3: Evaluation Strategy - From 'Similarity' to 'Quality'

After obtaining model outputs, the most primitive way is to manually review each one, but this is too inefficient for regression. A common method is to compute similarity between output and expected answer, such as BLEU, ROUGE, or cosine similarity. But there's a trap: LLM outputs are usually flexible; sentences with the same meaning but different wording may score low on BLEU, leading to false 'regression failure'.

In practice, I found a more practical combination: first use embedding similarity (e.g., text-embedding-3-small) to filter out clearly mismatched cases, then perform semantic validation on the remaining cases. Specifically, set a threshold: when embedding cosine similarity is below 0.75, mark it as 'needs manual review'. This threshold can be adjusted based on your business, but remember: similarity is not a panacea; it cannot catch factual errors.

So, for factual questionsFor such scenarios, I strongly recommend introducing a 'verification function'. For example, if the application extracts order numbers, the expected value in test cases can be a JSON rule, and the test runner will check whether the output contains order numbers that conform to the rule. Here is a simple example:

def check_fact(output, expected):
    # expected may be {'keyword': 'return policy'}
    if 'keyword' in expected:
        if expected['keyword'] in output:
            return True, 1.0
        else:
            return False, 0.0
    # other rules...
    return True, 0.8  # default pass but lower confidence

In real projects, I mix three evaluation methods: rule assertions (strict), similarity (lenient), and manual spot checks (fallback). During each regression test, if the number of cases with similarity below the threshold exceeds 5%, or if any rule assertion fails, I consider the test failed and need to roll back the prompt changes.

Step 4: Handling Model Uncertainty—Run Multiple Times and Take the Median

Even with a low temperature setting, LLM outputs still have randomness. Running the same prompt twice may yield slightly different results. To stabilize regression test results, I adopt a 'multiple runs' strategy: run each test case 3 times, get 3 outputs, then take the median or majority vote. For generation tasks, you can compare the pairwise similarity of the three outputs; if the three outputs differ significantly, it indicates that the case itself is unstable, and you may need to modify the test set or reduce the weight of that case.

This approach increases API call costs, but it brings more reliable test conclusions. On the DeepSeek API, the cost is quite low, and the expense of 3 calls is completely acceptable. I've seen teams that run only once to save money, resulting in random fluctuations in test results, which actually wastes more manual review time.

Additionally, pay attention to environment isolation in regression testing. I recommend fixing the model version during tests, not using a model like 'deepseek-chat' that may update (if you find it unstable, you can specify a specific snapshot version like 'deepseek-chat-0707'). I once encountered an online model upgrade that caused a sudden change in output style; fortunately, the regression test immediately alerted us, avoiding a bigger incident.

Step 5: Establish a Baseline Version and Comparison Report

The core of regression testing is 'comparison'. So, when running tests for the first time, save the results as the 'baseline version'. After each prompt modification, compare the new results with the baseline and generate a report that includes: output differences for each case, similarity scores, pass/fail status, and an overall pass rate.

In my project, I used the simplest solution: store results as JSON files, manage them with git, and use a script to generate a markdown report. The report lists all cases in a table, with checkmarks for passed items and crosses for failed ones. This way, during code review, reviewers can see risks at a glance. Here is a sample report excerpt:

This report must include a 'unstable cases' prompt, such as cases with large differences across multiple runs. These cases often expose problems in the test set itself or weaknesses of the model in specific domains, requiring special attention.

Step 6: Embed Regression Testing into CI/CD Pipeline

Prompt regression testing cannot stay at the manual stage. I strongly recommend making it part of the CI pipeline, automatically executing on every code commit or prompt file change. In GitHub Actions or GitLab CI, you can easily add a job that runs the test runner and blocks merging if the pass rate is below a threshold (e.g., 95%).

Here is a practical experience: test runtime should be kept under 3 minutes, otherwise developers won't want to wait. If the test set has 100 cases, each with 3 calls, and concurrency of 8, it takes about 1-2 minutes on the DeepSeek API, which is feasible. If it exceeds 5 minutes, consider reducing the number of cases or switching to a smaller model.

Also, be careful with secret management in CI; don't hardcode API keys in code, but use CI environment variables or secret management tools. I've had a mishap in my project where I accidentally committed a key to the repository, leading to a leak, and it took a lot of time to resolve.

Step 7: Engineering Pitfalls and Solutions in Practice

The first pitfall is the unexpected impact of the system prompt. Many teams' tests only cover user inputs, ignoring that the system prompt itself also needs regression. Once, to unify style, we changed a sentence in the system prompt from 'You are a smart customer service' to 'You are a professional customer service', and all answers became much longer, but similarity scores showed normal because vector distance is insensitive to style changes. It was eventually discovered through manual spot checks.

The second pitfall is output format stability. If your application requires JSON output, the LLM sometimes adds extra text before or after the JSON (e.g., 'Okay, here is the result:'), which can crash the parser. In regression testing, you must have format validation assertions. I usually use Python's json.loads to test if the output can be parsed; if not, it's a direct failure. But note that the DeepSeek API supports returning JSON mode (response_format), so it's recommended to enable it in API calls to reduce such errors.

The third pitfall is cost control. Frequent regression test runs can increase API costs. My usual approach is: run only a 'quick subset' (e.g., 20 core cases) on each commit, and run the full test set on a daily scheduled task. This ensures basic safety while controlling costs.

Conclusion: From 'Mystical Tuning' to 'Engineering Governance'

Prompt regression testing is not optional icing on the cake; it is a necessary checkpoint for LLM applications to move to production. It helps you maintain quality baselines and lets you optimize prompts without fear. On the DeepSeek API, these practices are fully feasible and cost-effective. But remember, this method is not a silver bullet; evaluation metrics cannot cover all semantic issues, and manual review must always be retained.

My suggestion is to start today by managing prompts like code: define test sets, write test runners, set quality thresholds, integrate into CI, and make every change evidence-based. This process may take a few days of investment, but the payoff is long-term stability. If you've encountered other pitfalls in practice, feel free to share in the comments, and together we can refine this methodology.