AI English Shift · Lessons / C02

Testing, debugging and changing code

测试、调试与代码修改

Open the interactive lesson · 打开互动课程

Debugging starts with a mismatch between expected and observed behavior, and the first useful artifact is a reproducible example.

调试始于预期行为与观察到的行为不一致,而第一个有用的产出是可复现的例子。

デバッグは期待と観察した動作の食い違いから始まり、最初に役立つ成果物は再現例です。

Reduce unnecessary conditions while preserving the failure, so the team can distinguish the triggering cause from unrelated complexity.

在保留故障的前提下,去掉不必要的条件,让团队能够区分触发原因与无关的复杂因素。

失敗を保ちながら不要な条件を減らすと、原因となる条件と無関係な複雑さを区別できます。

An AI assistant can propose hypotheses, but a plausible explanation should lead to a check rather than become the accepted diagnosis immediately.

AI 助手可以提出假设,但看似合理的解释应引出一项检查,而不应立即被当成确定的诊断。

AIは仮説を提案できますが、もっともらしい説明はすぐ確定診断にせず、確認につなげるべきです。

Inspect the input, relevant state, code path and actual output for the failing example.

针对失败的例子,检查输入、相关状态、代码路径和实际输出。

失敗例について、入力、関連する状態、コードの経路、実際の出力を調べます。

A unit test checks a bounded component, while an integration test checks interactions whose failures may be invisible in isolated components.

单元测试检查一个范围明确的组件,而集成测试检查组件之间的交互;这些交互中的故障,在孤立组件中可能看不出来。

単体テストは範囲を絞った部品を確認し、結合テストは個々の部品だけでは見えない連携の失敗を確認します。

Type checking and static analysis can detect important classes of mistakes, but valid types do not establish correct business behavior.

类型检查和静态分析能够发现一些重要类别的错误,但类型有效并不能证明业务行为正确。

型検査や静的解析は重要な種類の誤りを検出できますが、型が正しくても業務動作の正しさは証明できません。

A meaningful regression test would have failed on the original bug and now passes because the required behavior was restored.

有意义的回归测试,在原始缺陷存在时本应失败;现在之所以通过,是因为所需行为已恢复。

意味のある回帰テストは元の不具合では失敗し、求める動作が復元されたことで合格するものです。

Avoid tests that merely repeat the implementation's internal steps or assert a success message that the broken code already displays.

应避免编写只是重复实现内部步骤的测试,也不要仅仅断言出现了一条成功消息,而有缺陷的代码本来就会显示这条消息。

実装内部の手順を繰り返すだけのテストや、壊れたコードも表示する成功メッセージだけを見るテストは避けます。

Review the change for new assumptions, handling of missing data, and behavior at the boundary that produced the defect.

审查修改时,应检查它是否引入新假设、如何处理缺失数据,以及在导致缺陷的边界情况下会如何表现。

変更に新しい仮定がないか、欠損データの扱い、不具合を起こした境界での動作を確認します。

Run the checks appropriate to the changed behavior, then expand investigation when a failure or unresolved concern justifies it.

先运行适合此次行为修改的检查,再在出现失败或仍有疑虑时扩大调查范围。

変更した動作に合う検査を行い、失敗や未解決の懸念があれば調査を広げます。

The final explanation should connect the bug trigger, the correction and the evidence, making it possible for another person to verify the result.

最终说明应把缺陷的触发条件、修复方式和证据连接起来,让其他人能够验证结果。

最終説明では、発生条件、修正、証拠をつなぎ、別の人が結果を確認できるようにします。

Key terms