ds-verify-loop

ds-verify-loop

実際のチェックを実行し、その結果に基づいて修正することで、変更が機能することを証明します。予想される結果に基づいて修正してはいけません。

手順

1. 編集する前にチェックを選びます。変更を証明できる、最も範囲の狭い実際のコマンドを選びます。たとえば、テストファイルを1つ実行する、型チェックを行う、ビルドする、またはリクエストを1つ送ってアプリを実行する方法があります。コマンドを書き留めておきます。
2. 可能であれば、編集前に一度実行して、ベースラインを確認します（すでに失敗している、すでに成功している、または別の理由で壊れている）。
3. チェックを通すために必要な、最小限の編集を行います。
4. 正確に同じコマンドを実行します。最初のエラー、ファイルと行、コード内のスタックフレームを含め、エラー出力全体を読みます。最後の行だけを流し読みしてはいけません。
5. 出力に基づいて、根本原因を1文で述べます。それができない場合は、printまたはログを1行追加するか、失敗したコードを読んでから再実行します。推測してはいけません。
6. 症状ではなく原因を修正します。テストで使われている入力1つだけを対象にした特別なケースを追加してはいけません。
7. 同じコマンドを再実行します。これを1回の反復として数えます。
8. 範囲の狭いチェックに合格したら、より広いチェックを一度実行します（テストスイート全体、ビルド、またはlintなど）。ほかの箇所への影響を検出します。
9. 最終的に合格した出力（コマンドと最後の数行）を、返信またはPROGRESS.mdに貼り付けます。

次の場合に停止します

• チェックに合格し、出力を貼り付けた場合。出力のない主張は認められません。
• 合格せずに5回反復した場合。編集を停止し、最後のエラーを報告して、ds-unstickに切り替えます。
• 異なる2つの修正を行った後に、同じエラーが2回発生した場合。すぐにds-unstickに切り替えます。5回目の反復まで待ってはいけません。

ルール

• チェックに合格させるために、テスト、アサーション、型、lintルールを弱めたり、省略、削除、緩和したりしてはいけません。テストに誤りがある場合は、その理由を伝えて、まず確認を求めてください。
• テスト対象をモックで置き換えてはいけません。
• 毎回、実際のコマンドを実行します。実行すると何が出力されるかを推測してはいけません。
• 何を修正したら解決したかを把握できるよう、1回の反復につき変更は1つだけにします。
• チェックが存在しない場合は、変更前には失敗する最小限のチェックを作成してから、このループを実行します。