京公网安备11010502063487号本机 hypothesis 6.168.3 真实测一个行程编码函数:手写 7 个例子全部通过,而 property「decode(encode(s)) == s」在第 7 个随机输入 Ö7 就失败并缩小到最小反例 "0";第一次「修复」排除 Nd 类别仍被发现 "²"(isdigit 为真但类别是 No)引起 ValueError;失败例子被记入 .hypothesis 数据库,第二次运行只调用 2 次就复现。
本机 coverage 7.16.2 真实验证覆盖率的含义:一个只调用不断言的测试行覆盖 100%、行+分支覆盖 82%,却完全发现不了「会员订单价格变负」的 bug;补齐分支后仍是 100% 却仍无断言;没被 import 的文件默认不进报告(100% → 加 --source=. 后 73%);# pragma: no cover 直接改变数字;3 万行不同代码各跑一次时开销 54x(行)/145x(分支),反复跑的热循环几乎无开销。
本机用 tox 4.64.4 和 nox 2026.8.17 在 Python 3.12.14 与 3.14.7 上跑同一份检查:py312 因为没有 annotationlib 和 t-string 语法失败、py314 通过,两者都各自建了虚拟环境(.tox/py312、.nox/tests-3-12 等);tox 首次 0.8 s、复用 0.2 s、-r 重建 0.5 s;nox 的 session 是 Python 函数,可以按 session.python 写条件。
本机真实对同一段乱序代码跑 black、isort、ruff:格式化与 import 排序是两件事,三者都不会删除未使用的 import(ruff 的 F401 才会报);isort 默认配置生成的网格式 import 会被 black --check 判失败,加 --profile black 后一致;ruff(I)+ruff format 与 isort+black 输出逐字相同;300 文件下 black 918 ms 对 ruff format 24 ms、isort 229 ms 对 ruff 26 ms。
本机 mypy 2.3.1 在一个旧项目上真实逐档收紧:默认配置 0 个错误、--check-untyped-defs 2 个(暴露 int + str 的真实 bug)、--disallow-untyped-defs 10 个、--strict 14 个;无注解函数返回 Any 让新代码的错误被放过;按模块设置「legacy 忽略、newcode strict」得到 3 个错误;增量缓存下重跑 0.10 s。
本机 mutmut 3.8.0 真实对一个 13 行、覆盖率 100% 的小模块做变异测试:11 个变异体里 5 个被杀死、6 个存活(clamp 无断言、is_adult 只测 30、total 只测 tax=0);补上边界断言后 9 个杀死、2 个存活,那 2 个是无法被杀死的等价变异体(x <= lo 与 x < lo 在 x==lo 时返回值相同)。
本机真实验证:依赖真实时钟的测试在一天 24 个整点里只有 8 个通过;patch("time.time") 对 from time import time 拿走的引用无效、patch 内置类型 datetime.now 报 TypeError;把时钟当参数传入可免于 patch;共享全局 random 状态会造成 a→b 通过而 b→a 失败;禁外网 fixture 让不可达地址的连接由 0.60 s 超时变成 0.0003 s 立刻报错;patch 掉 sleep 让重试测试从 1.12 s 降到 0.07 s。
本机真实验证并发测试的稳定性:一段「先读后写」的存款代码自然运行 10 次全部正确(800),加一个线程让出点后 10 次全部错误(200 多);用两个 Event 排演「A 读→B 读→B 写→A 写」每次都稳定复现丢失更新(余额 1,期望 2),加锁后得 2;并用 join(timeout) 和 subprocess 超时避免卡死、用轮询代替固定 sleep(任务 20 ms 时 21 ms 通过)。
本机用 100 个真实线程冲击一个先宕机 300 ms、之后每 20 ms 只能处理 15 个请求的服务:固定 50 ms 间隔产生每格整整 100 个请求的「请求墙」(133 次限流拒绝、579 ms 完成);指数退避无抖动仍然齐发(174 次拒绝、1636 ms,最慢);加全抖动后 0 次限流拒绝、606 ms 完成。并验证只应对暂时性错误重试。
本机自己实现熔断器并对一个 0.5–1.5 s 故障的下游做对照(8 个工作线程):50 请求/秒时熔断器把打到下游的调用从 150 次降到 86 次、故障期失败延迟从约 155 ms 降到 0.1 ms,但下游 1.5 s 就恢复而熔断器到 2.04 s 才恢复放行;100 请求/秒(超过线程池能力)时无熔断器的请求排队,故障期延迟中位 373 ms、最大 601 ms,有熔断器中位 0.1 ms。
本机用可注入的时钟实现固定窗口、滑动窗口日志、令牌桶、漏桶四种限流器并对比:跨窗口边界的突发下固定窗口放行 20/20(限制 10/s 的两倍)而滑动窗口 10、令牌桶 6;t=0 涌来 50 个请求时令牌桶只放行容量 5 个;持续高压下令牌桶任意 0.1 s 最多 5 个而固定窗口 10 个;8 个线程下加锁放行 419、不加锁 976(理论上限约 420)。
本机真实用 6 种方式处理正在执行第 3 个任务时收到的 SIGTERM:默认处置立刻被杀(丢失任务、cleanup 不执行);只设停止标志在 0.18 s 内做完手头任务并干净退出(退出码 0);处理函数里 sys.exit(0) 遇到普通工作线程根本退不出去(父进程等了 3 s 只能 SIGKILL),遇到守护线程则秒退但丢弃在途任务;任务卡死时只设标志会永远等下去,加 1 秒看门狗则 1.06 s 强退。