函数测试用例

下面是针对 parseMoney 的高价值单元测试清单，按主题分类，包含预期结果或错误。在需要时标注可能的失败点与实现差异风险。

基本有效用例（en-US）

• "123" -> 12300
• "1,234" -> 123400
• "1,234.56" -> 123456
• "1234.56" -> 123456
• "0001.23" -> 123
• "$1,234.56" -> 123456
• "€1,234.56" -> 123456
• "¥1,234.56" -> 123456
• "+1,234.56" -> 123456
• "-1,234.56" -> -123456

基本有效用例（de-DE）

• "123" -> 12300
• "1.234" -> 123400
• "1.234,56" -> 123456
• "1234,56" -> 123456
• "0001,23" -> 123
• "€ 1.234,56" -> 123456（前后空白被忽略）
• "+1.234,56" -> 123456
• "-1.234,56" -> -123456

括号负数

• "(123.45)" en-US -> -12345
• "($1,234.56)" en-US -> -123456
• "(1.234,56)" de-DE -> -123456
• 注意："+(123.45)" 和 "-(123.45)" 应抛错（括号不在首尾包裹整个值），见“非法格式”。

符号、空白与货币符号位置

• " $ 1,234.56 " en-US -> 123456
• "$1,234.56€" en-US -> 123456（多个货币符号被移除）
• "¥(1,234.56)" en-US -> -123456
• "€-1.234,56" de-DE -> -123456
• " -$0.00 " en-US -> 0

四舍五入到分（关键边界）

• "0.004" en-US -> 0
• "0.005" en-US -> 1（潜在浮点误差风险）
• "(0.005)" en-US -> -1
• "1.234,5678" de-DE -> 123457（超过2位小数，四舍五入）
• "123.4567" en-US -> 12346
• "1.2" en-US -> 120
• "1,2" de-DE -> 120
• 易出错案例（JS 浮点）："2.675" en-US 期望 -> 268；实际 Math.round(2.675*100) 可能得到 267
  • 同理 "2,675" de-DE 期望 -> 268；可能得到 267
• 说明：JS Math.round + 二进制浮点表示可能导致半入误差，建议在测试中加入此类样例以暴露问题。

数字类型输入（快捷路径）

• 1234.56 -> 123456
• -1234.56 -> -123456
• 0 -> 0
• -0 -> 0（JS 中 -0 === 0；若要显式规避 -0，可断言等值为 0）
• 1.005 -> 期望 101；实际可能 100（浮点误差）
• -1.005 -> 期望 -101；实际可能 -100（浮点误差 + Math.round 对负数的行为）
• Infinity/NaN -> 抛错 'input must be string or finite number'

非法格式（应抛错）

• 空/仅空白："", " " -> 'empty input'
• 不支持地区：locale='fr-FR' -> 'unsupported locale'
• en-US：错误千分位
  • "12,34.56" -> 'invalid en-US money format'
  • "1,23" -> 'invalid en-US money format'
  • "1,234." -> 'invalid en-US money format'
  • "1,234,567.89.10" -> 'invalid en-US money format'
  • "1,234.56)" 或 "(1,234.56" -> 'invalid en-US money format'
  • "()", "$"（变成空）-> 'invalid en-US money format'
  • "USD 1,234.56"（包含字母）-> 'invalid en-US money format'
  • "++123"（仅移除一个 +，仍不匹配）-> 'invalid en-US money format'
  • "123.45-" -> 'invalid en-US money format'
  • "−123.45"（Unicode 负号 U+2212）-> 'invalid en-US money format'
  • "1.234,56"（de-DE 格式）-> 'invalid en-US money format'
• de-DE：错误千分位/小数
  • "1.234.56" -> 'invalid de-DE money format'
  • "1,234.56"（en-US 格式）-> 'invalid de-DE money format'
  • "(1.234,56" 或 "1.234,56)" -> 'invalid de-DE money format'
  • "1 234,56" 使用窄不间断空格 U+202F -> 'invalid de-DE money format'（可能未被 \s 移除，注意国际化空白字符差异）
• 其他
  • "-(123.45)" -> 'invalid en-US money format'（减号处理后剩余括号，正则失败）
  • "((123.45))" -> 'invalid en-US money format'（切一次括号后仍有括号）
  • "1-234" -> 'invalid en-US money format'

极值与精度风险

• 非常大数（安全整数边界）
  • "90,071,992,547,409.91" en-US -> 9007199254740991（恰好等于 Number.MAX_SAFE_INTEGER，应可精确表示）
  • "90,071,992,547,409.915" en-US -> 9007199254740992（超过安全整数，可能产生精度错误；当前实现不会检出此问题）
  • "9,223,372,036,854,775.80" en-US（超大）-> 返回一个不可精确的数字，建议在测试中捕获/记录此精度风险

地区不匹配（确保严格性）

• en-US 下 "1.234,56" -> 'invalid en-US money format'
• de-DE 下 "1,234.56" -> 'invalid de-DE money format'

额外建议的属性/随机测试

• 生成随机合法的 en-US/de-DE 金额字符串，与使用高精度十进制库（如 decimal.js 或 big.js）计算的期望值对比，验证四舍五入与千分位处理。
• 属性测试：对不含分隔符的十进制字符串 x，parseMoney(x) 应等于 Math.round(Number(x)*100)（注意浮点误差）；或改用高精度库得到期望。
• 一致性测试：parseMoney(String(n, locale)) 与 parseMoney(n) 在非极端/无浮点边界的情况下应相等。

备注：当前实现存在的已知风险点

• JS 浮点导致的四舍五入误差（典型 2.675、1.005 等），包括数字类型路径与字符串路径。
• 返回值可能为 -0（数值上等于 0，但有时会影响显示或 Object.is 判断）。
• 超过 Number.MAX_SAFE_INTEGER 的分值时精度不可控；如需要，应在实现中加入边界检查并抛错或改用高精度库。

下面是一组面向该方法的高价值单元测试用例与设计建议，覆盖你列出的关注点与一些潜在失败点。每个用例都尽量给出构造方式、断言要点以及避免测试不稳定的策略。

基础准备与通用建议

• 使用 JUnit 5；对时间相关断言使用 System.nanoTime 并设置宽松容差，避免 CI 上的抖动。
• 大多数时间相关测试将 jitter 设为 0 或 baseDelay 设为 0，以减少随机性与等待时间。
• 构造辅助 Callable：
  • failNTimesThenSucceed(n, exSupplier, returnValue)：前 n 次抛出 exSupplier.get()，第 n+1 次返回 returnValue。
  • alwaysFail(exSupplier)：每次都抛出 exSupplier.get()。
  • succeed(value)：立即返回 value。
• 构造 retryOn Predicate：
  • retryOnAll：永远返回 true。
  • retryOnlyOn(Class<? extends Exception>)：仅对某个异常类型返回 true。
  • countingPredicate(delegate)：包装 predicate，记录调用次数，便于断言。
• 避免 30s 上限相关测试变慢：在需要“进入睡眠”但不想等满上限时，考虑在单独线程中调用方法，并在进入睡眠后短时间内 interrupt 该线程，验证中断分支与状态，而非真实等待。

参数校验（非法参数）

• task 为 null：
  • 输入：task=null, 其它参数合法。
  • 期望：IllegalArgumentException，消息包含 "null args"。
• retryOn 为 null：
  • 输入：retryOn=null。
  • 期望：IllegalArgumentException，消息包含 "null args"。
• maxAttempts < 1：
  • 输入：maxAttempts=0 或负数。
  • 期望：IllegalArgumentException，消息包含 "maxAttempts >= 1"。
• baseDelay 为负：
  • 输入：Duration.ofMillis(-1)。
  • 期望：IllegalArgumentException，消息包含 "baseDelay >= 0"。
• jitter 越界：
  • 输入：jitter = -0.1 或 1.1。
  • 期望：IllegalArgumentException，消息包含 "jitter in [0,1]"。

边界与核心行为

• 成功立即返回（首次尝试成功）：
  • 输入：succeed("OK"), maxAttempts=3, baseDelay 任意, jitter=0, retryOnAll。
  • 期望：返回 "OK"；Callable 仅调用 1 次；无等待。
• maxAttempts=1 的边界（成功与失败）：
  • 成功：succeed("OK"), maxAttempts=1 -> 返回 "OK"，仅调用 1 次。
  • 失败（异常可重试）：alwaysFail(new RetryableException), maxAttempts=1 -> 立即抛出该异常，不进行重试与睡眠。
• 非重试异常立即抛出：
  • 输入：Callable 第一次抛出 NonRetryableException；retryOn 仅对 RetryableException 返回 true。
  • 期望：第一次就抛出 NonRetryableException；Callable 调用 1 次；无睡眠；predicate 调用 1 次。
• 可重试直至成功：
  • 输入：failNTimesThenSucceed(n=3, RetryableException, "OK"), maxAttempts=5, baseDelay=Duration.ofMillis(5), jitter=0, retryOnAll。
  • 期望：返回 "OK"；Callable 调用 4 次；predicate 调用 3 次。
  • 可选：测量耗时 ≥ 5+10+20ms（允许宽松容差），但不建议做严格时间和精确总和断言以避免抖动。
• 最终失败（耗尽重试次数）：
  • 输入：alwaysFail(RetryableException), maxAttempts=3, baseDelay=Duration.ofMillis(5), jitter=0, retryOnAll。
  • 期望：抛出最后一次的异常实例（同一对象）；Callable 调用 3 次；predicate 调用 3 次。

时间与抖动（jitter）相关

• baseDelay=0 不应睡眠：
  • 输入：alwaysFail(RetryableException), maxAttempts=3, baseDelay=Duration.ZERO, jitter=1, retryOnAll。
  • 期望：总耗时接近 0（小于比如 10ms 容差）；Callable 调用 3 次；predicate 调用 3 次。
• jitter=0 的确定性：
  • 输入：failNTimesThenSucceed(n=1,...), baseDelay=Duration.ofMillis(50), jitter=0, retryOnAll。
  • 期望：第一次失败后睡眠约 50ms（允许容差）；然后成功。
• jitter=1 边界范围：
  • 输入：failNTimesThenSucceed(n=1,...), baseDelay=Duration.ofMillis(100), jitter=1, retryOnAll。
  • 期望：第一次失败后睡眠时间位于 [0ms, 200ms] 范围（给足容差，比如 [-5ms, 230ms]）。
  • 注意：使用 System.nanoTime，允许较宽的上界容差避免 CI 抖动。
• 多次采样（可选，非必须）：
  • 重复运行若干次，观察睡眠分布，确保不会出现负数或超过 2×delay（考虑到 cap 未达时）。

延迟封顶（cap）行为

• 达到封顶（30s）的逻辑检查：
  • 说明：方法使用 maxCap = Math.max(baseMillis, 30_000L)，因此当 baseDelay < 30s 时上限是 30s；当 baseDelay > 30s 时，上限是 baseDelay 本身（这可能不是常见的“固定 30s 封顶”，值得特别验证和评审）。
  • 慢测（可 @Disabled 或打标记）：baseDelay=Duration.ofMillis(30), maxAttempts 足够大（如 11）且 jitter=0，理论上第 11 次应被封顶为 ~30s。验证单次尝试的睡眠不超过 ~30s（允许容差），但这会非常慢。
  • 替代策略（推荐）：在单独线程中运行 alwaysFail，设置 baseDelay=Duration.ofMillis(30), jitter=0, maxAttempts=11；在预计进入长睡眠（第 11 次）时短时间后 interrupt 线程。断言：
    • 抛出的异常是上一次任务抛出的异常（非 InterruptedException）。
    • 线程的中断位已被设置（Thread.interrupted() 为 true）。
  • 设计评审建议：若预期是“固定上限 30s”，应使用 min(delay, 30_000L) 而非 Math.max(base, 30_000L)。可增加一个专门测试当 baseDelay>30s 时，延迟被封顶为 baseDelay 而非 30s，以暴露此行为差异（由于时间过长，可标记为慢测或以 interrupt 技巧缩短）。

线程中断

• 睡眠期间被中断：
  • 场景：alwaysFail(RetryableException), baseDelay=Duration.ofMillis(150), jitter=0, maxAttempts=3, retryOnAll。
  • 在单独线程中调用 retryWithJitter；主线程延时 ~20ms 后 interrupt。
  • 期望：
    • 抛出的异常实例为最后一次 task 抛出的异常（即重试异常），而不是 InterruptedException。
    • 调用线程的中断位被设置（catch 后有 Thread.currentThread().interrupt()）。
    • Callable 调用次数至少为 1（中断发生在第 1 次失败后的睡眠期间）。
  • 注意：无需精确睡眠时长断言，只验证分支与状态。

谓词逻辑与异常传播

• predicate 决策次数与时机：
  • 使用 countingPredicate(retryOnAll)，配合 alwaysFail，确保 predicate 调用次数等于失败次数。
• predicate 抛异常：
  • 场景：task 抛出 RetryableException；predicate.test(ex) 内部抛出 RuntimeException("boom")。
  • 期望：方法直接传播该 RuntimeException；不进一步睡眠或重试。
• 混合异常序列与选择性重试：
  • 场景：任务先抛 RetryableException，再抛 NonRetryableException；retryOn 仅重试 RetryableException。
  • 期望：第一次失败进入睡眠；第二次遇到非重试异常立即抛出；总调用次数为 2；第二次抛出时不再睡眠。

返回值与异常一致性

• 返回 null：
  • 场景：succeed(null)。
  • 期望：方法正确返回 null，不发生 NPE。
• 抛出的异常对象是否为原始实例：
  • 最终失败或中断路径，断言抛出的异常与最近一次 task 抛出的实例为同一对象引用（==），而不是新包裹的异常。

精度与数值边界

• 不会产生负睡眠值：
  • 场景：jitter=1 时 factor 可为 0；baseDelay 任意正值。
  • 期望：睡眠时长为 0 或正数（方法内部已有 Math.max(0, ...) 防护）。可通过 baseDelay=0 或 jitter=1 的组合来走到 sleepMs=0 分支。
• 尝试次数较大时的指数计算：
  • 说明：exp = (long)Math.pow(2, attempt-1) 为 double 转 long，理论上 attempt 到 63 仍在 long 正范围，但由于 cap 存在，通常不会到达该边界。建议不做过多精确测试，保持参数在合理范围。

可维护性与测试稳定性建议

• 对时间相关断言使用较小 baseDelay（如 5–50ms）与 jitter=0，避免长时间阻塞。
• 涉及 cap=30s 的测试单独标记为慢测或使用线程中断技巧缩短时间。
• 用 System.nanoTime 代替 currentTimeMillis 进行耗时测量。
• 对随机性（jitter=1）相关测试允许较宽容差，并尽量仅验证范围而非精确值。
• 若未来可重构 RetryUtil，建议引入可注入 Sleeper 接口（代替直接调用 Thread.sleep），以便在单元测试中用假的 Sleeper 验证精确的延迟与 cap 逻辑，提升可测性与速度。

通过以上用例与策略，基本可以覆盖：

• maxAttempts=1 的边界
• jitter 的 0 与 1 边界
• baseDelay=0 的特殊路径
• 非重试异常立即抛出
• 到达封顶延迟（含行为评审）
• 线程中断路径与中断位一致性
• 可重试到成功与最终失败两条主路径
• 参数校验与谓词异常传播等潜在失败点