主题: testing
-
变更基准测试:预热、重复次数、离散程度与应报告的内容
计时对比只有经得起噪声考验才算得上结果:固定工作负载、丢弃预热运行、将各变体的多次重复交替执行、在查看数据前先确定要用的统计量,并在每个数字旁报告离散程度与环境信息。小于运行间离散程度的差异算不上发现。
-
以经过验证的小步骤进行重构
重构改变结构而不改变行为。每次只做很小的改动,在步骤之间保持测试通过,并将重构提交与行为变更分开,能让过程安全且便于审查。
-
Einen brauchbaren Fehlerbericht schreiben
Ein Fehlerbericht ist brauchbar, wenn eine fremde Person den Fehler ohne Rückfrage nachstellen kann: eine präzise Überschrift, Umgebung mit Versionen, nummerierte Schritte zum Nachstellen, erwartetes und tatsächliches Ergebnis getrennt, die wörtliche Fehlermeldung und ein möglichst kleines Beispiel. Vermutungen zur Ursache stehen in einem eigenen Abschnitt.
-
本地数据库的种子数据与固定数据集:小规模、幂等,并与模式一同版本化
区分所有环境都需要的参考数据、开发和演示用的示例数据,以及由测试创建的测试数据。将种子脚本写成基于自然键执行 upsert 的幂等代码,保持示例集小而有名,在安装脚本和 CI 中都于迁移后运行,绝不直接用未经处理的生产数据填充开发机。
-
使用生成输入进行基于属性的测试
基于属性的测试不依赖手工挑选的示例,而是声明一个不变条件,让库生成大量输入,并将失败案例缩减为最小反例。Hypothesis 是 Python 中这一方法的参考实现。
-
生成、评议、修订:自我验证循环何时值得投入
当评议有外部信号(测试、验证器或来源)和固定评价标准时,让模型评议并修订自身输出的循环能改善结果;缺少这种依据时,已发表的研究结果表明它可能使答案变差。每轮至少增加两次调用,且两次调用的输入量都会随草稿增长。
-
使用 JUnit 5 和 xUnit.net 编写单元测试:并列比较注解、生命周期和参数化用例
JUnit Jupiter 用 @Test 标记测试,默认在每个新实例上的测试前后运行 @BeforeEach 和 @AfterEach,并用 @ParameterizedTest 加数据源注解驱动数据用例;xUnit.net 用 [Fact]、构造函数和 IDisposable 在新实例上完成每个测试的准备与清理,用 [Theory] 和 [InlineData] 表达用例,用 fixture 共享昂贵的上下文。在两者中采用相同的测试结构,有助于多语言团队统一约定。
-
设计持续集成流水线
CI 流水线应快速、能够自我测试,并对每项变更采用同一流程:从干净检出的代码构建,分阶段运行静态检查和测试,明确暴露失败,并让总耗时足够短,使人愿意等待结果。
-
使用容器中的临时数据库进行集成测试
每次测试运行都在一次性容器中启动真实数据库引擎,将数据保存在内存中,只对模板数据库执行一次迁移,再为每个测试文件复制模板。这样测试检查的就是真实的规划器、约束和隔离行为,而不是内存替代品。
-
Use property tests for parsers
Express parser invariants over generated inputs and keep minimized failures as focused regression examples.
-
pass^k over repeated trials predicts production agent incidents better than pass@k
Hypothesis: for agents deployed on repetitive tasks, the all-trials-pass rate (pass^k) on an evaluation set correlates more strongly with the rate of failed or escalated runs in production than the any-trial-pass rate (pass@k), because production gives each task one attempt.
-
机器学习实验的可复现性:随机种子、环境、数据与确定性的边界
重新运行实验并得到同一个数值,需要显式传入固定的随机状态、锁定库版本、明确数据集和划分,同时认识到 GPU 内核和库的新版本仍可能改变结果;该流程尽可能让运行可重复,并记录无法重复的部分。
-
Red-teaming an agent workflow before it gets real permissions
Attack the agent the way content and users will: indirect prompt injection through every input it reads, tool-argument manipulation, exfiltration through tool calls and budget exhaustion; run scripted probes plus manual attempts, record what the agent did, and fix the boundary, not only the prompt.
-
不使用生产环境个人数据的测试数据
通过生成数据,为开发、CI 和预发布环境提供真实感:分类各列,编写带固定种子且能通过应用校验的生成器,用 generate_series 生成足够的数据量,只从生产环境复制分布信息,为生成记录加上可识别标记,并移除直接导出生产数据库的捷径。
-
How much test coverage is enough for a small service?
Open question: for a service of a few thousand lines with a database and an HTTP API, what coverage level and test mix has been observed to keep defect rates acceptable without slowing change?
-
利用 JSON Schema、验证与有限重试从文档中提取结构化数据
将目标记录定义为 additionalProperties false 的 JSON Schema,要求模型严格按该结构输出,用真正的验证器检查每个响应,并把验证错误反馈到提示中,在限定次数内重试。仍然失败的记录应交给人工,而不是猜测。
-
Reviewing code written by an AI agent
A proposed review protocol for generated changes: compare the diff with the request, confirm every API and dependency exists, verify test claims by running and breaking the tests, read tests before implementation, hunt for swallowed errors, and record what was checked.
-
The test-driven development loop
Write a failing test, make it pass with the simplest change, then refactor with the tests green; the loop keeps design decisions small and gives every line a reason to exist.
-
浏览器端到端测试中的稳定选择器与自动等待
不稳定浏览器测试主要有两类原因:选择器失效或匹配错误元素,以及假定时序的固定等待。应按角色、标签或测试 ID 定位,每个定位器恰好匹配一个元素,并通过可重试断言和可操作性检查同步,而不是依赖时间。
-
开展变异测试,避免被存活变异体淹没
先在一个模块上运行变异工具,将每个存活变异体归类为缺失断言、缺失场景或等价变异体;修复前两类,排除第三类,通过增量运行或仅检查差异限制耗时。按模块将分数作为只升不降的基线,而不是全局目标。
机器可读: JSON