如何系统验证多语言数字翻译Python代码的正确性？

Great question—testing translators that handle an infinite range of numbers is definitely tricky, but there are practical, systematic ways to validate your code without checking every possible value. Let’s break down actionable strategies you can implement right away:

First, let’s anchor our approach to the three core layers of your system—validating each independently will make it easier to spot where issues might creep in:

1. English ↔ Arabic numerals
2. Arabic numerals ↔ German (with the critical tens/units inversion rule)
3. Full round-trip integrity (English → Arabic → German → Arabic → English, and vice versa)

1. Targeted Unit Tests for Core Logic #

Start with small, focused unit tests to lock in the basic building blocks of your translator. These catch edge cases in individual number components that manual testing might miss:

• Single digits: one ↔ 1 ↔ eins, five ↔ 5 ↔ fünf
• Tens values: twenty ↔ 20 ↔ zwanzig, ninety ↔ 90 ↔ neunzig
• Inverted tens-units pairs (German’s signature quirk): twenty-five ↔ 25 ↔ fünfundzwanzig, seventy-three ↔ 73 ↔ dreiundsiebzig
• Large scale numbers: three hundred ↔ 300 ↔ dreihundert, two thousand five hundred ↔ 2500 ↔ zweitausendfünfhundert
• Edge cases: zero ↔ 0 ↔ null, one hundred one ↔ 101 ↔ einhunderteins

You can automate these with Python’s built-in unittest or pytest. Here’s a quick example snippet:

import pytest
from your_module import eng_to_arabic, arabic_to_german, german_to_arabic, arabic_to_eng

def test_single_digit_roundtrip():
    assert eng_to_arabic("seven") == 7
    assert arabic_to_german(7) == "sieben"
    assert german_to_arabic("sieben") == 7
    assert arabic_to_eng(7) == "seven"

def test_german_tens_inversion():
    assert arabic_to_german(42) == "zweiundvierzig"
    assert german_to_arabic("zweiundvierzig") == 42

2. Property-Based Testing for Infinite Range Coverage #

Since you can’t test every number, property-based testing lets you generate thousands of random values and verify that your code adheres to unbreakable rules. Tools like hypothesis are perfect for this:

• Define core properties that must always hold:
  • Round-trip invariant: For any valid number n, german_to_arabic(arabic_to_german(n)) == n and eng_to_arabic(arabic_to_eng(n)) == n
  • German inversion rule: For numbers 11-19 and 21-99 (excluding multiples of 10), the German string should place the unit first, followed by und, then the ten (e.g., 37 → siebenunddreißig)
  • Scaling correctness: eng_to_arabic("one thousand") * 5 == eng_to_arabic("five thousand"), arabic_to_german(1000 * 7) == "siebentausend"

Example using hypothesis:

from hypothesis import given
import hypothesis.strategies as st

@given(st.integers(min_value=0, max_value=10**9))  # Test up to 1 billion (adjust as needed)
def test_arabic_german_roundtrip(n):
    german_str = arabic_to_german(n)
    assert german_to_arabic(german_str) == n

@given(st.integers(min_value=11, max_value=99).filter(lambda x: x % 10 != 0))
def test_german_inversion_property(n):
    german_str = arabic_to_german(n)
    unit = n % 10
    ten = n // 10 * 10
    # Verify the unit comes before "und" and the ten term
    unit_str = arabic_to_german(unit)
    ten_str = arabic_to_german(ten)
    assert unit_str in german_str
    assert ten_str in german_str
    assert german_str.index(unit_str) < german_str.index("und")
    assert german_str.index("und") < german_str.index(ten_str)

3. Explicit Edge Case & Boundary Testing #

Even with random generation, some boundary values need manual checks—these are the cases that often break number parsers/generators:

• Numbers with optional "and" (if your code supports it): one hundred and five ↔ 105 ↔ einhundertfünf
• Large-scale terms: one million ↔ 1000000 ↔ eine Million, one billion ↔ 1000000000 ↔ eine Milliarde (note German’s difference between "Million" and "Milliarde")
• Negative numbers (if supported): negative twenty ↔ -20 ↔ minus zwanzig
• Zero in compound phrases: one thousand and zero (if allowed) ↔ 1000 ↔ eintausend

4. Fuzz Testing for Robustness #

To ensure your parsers handle unexpected input gracefully, use fuzz testing to throw malformed or mixed strings at eng_to_arabic and german_to_arabic. Tools like Python’s fuzzingbook can help here—you’ll want to verify that your code either returns the correct value or raises a meaningful error instead of crashing. For example:

• Generate random strings mixing valid number words and garbage (e.g., two thousand xxx forty five) and check for controlled failures.

Combining these methods gives you a solid safety net: unit tests catch known cases, property-based testing validates general rules across infinite inputs, and edge/fuzz testing handles the weird, unanticipated scenarios.

内容的提问来源于stack exchange，提问作者Homunkulus