デバッグツールと、多くの開発環境に欠けている工程

カテゴリ別のデバッグツールと、それぞれの前提

いずれのツールも、すでに不具合にたどり着いていることを前提としています。そして実際に何時間も費やされるのは、その前提を満たすまでの工程です。

欠けている工程

確実な再現手順は、デバッグにおいて最も価値の高い成果物であると同時に、最も用意されていないものでもあります。これがなければ推測に頼るしかなく、逆にこれさえあれば、ほかのあらゆるツールがただちに力を発揮します。

再現手順を確実なものにするのは、それが誰かの記憶の中ではなく、期待される結果とともに手順として書き出されていることです。書き出されていれば、再実行でき、他の人に引き継げ、修正後も残しておけます。

コーディングエージェントを使う場合にいっそう重要になる理由

修正を担うのがエージェントの場合、曖昧な説明は人間が相手のとき以上に大きな問題になります。人間であれば、スクリーンショット1枚から意図を推し量れます。一方エージェントには、手順と、期待との食い違いを明示的に伝える必要があります。それに満たない情報しか与えられなければ、見当違いの箇所を自信たっぷりに修正してしまいます。

試すべき順序

すぐに原因を説明できない不具合に出くわしたときは、最初に思いついた仮説を追うよりも早く答えに収束する順序があります。最初の仮説はたいていコードに関するものですが、答えはコードにないことが多いからです。

完全にクリーンな状態からでも発生しますか。発生しないのであれば、原因は残存した状態であり、コードには、あなたが考えているような問題はありません。

別の環境でも発生しますか。発生しないのであれば、環境同士の違いそのものが不具合であり、コードの差分を読み続ける必要はありません。

毎回発生しますか。そうでないのであれば、原因はタイミングか並行処理であり、これから検証しようとしていた決定論的な原因の大半を除外できます。

3つの問いに数分かけるだけで、それぞれの答えが原因の一群をまるごと除外してくれます。デバッグに費やされる時間の大半は、これらの問いのいずれかを立てていればただちに除外できたはずの領域を調べることに使われています。

再現手順は後まで残す

不具合を確認するために作ったテストケースは、そのまま再発を防ぐチェックになります。多くのチームはそれをブランチと一緒に削除してしまいます。だからこそ、半年後に同じ不具合が戻ってきても、誰もそれに気づけないのです。

ローカルに何もインストールしたくない場合は、同じセットアップを TestSprite のダッシュボードから行えます。CLI のその他の機能は CLI リポジトリにあります。

• GitHub App は、TestSprite のダッシュボードで設定する webhook です。パイプラインがすでに発行しているデプロイイベントを検知するため、リポジトリ側には何の変更も必要ありません。

• GitHub Actions は、この工程を自身のワークフローの中に組み込むもので、設定はターミナルから行います。

TestSprite はどのように欠けている工程を補うのか

TestSprite は、再現手順を成果物に変えます。手順と、最終的にどうなっているべきかを記述すると、デプロイ済みのアプリケーションに対して実行し、実際に何が起きたのかを報告します。これこそが、ほかのすべてのデバッグツールが「すでに手元にあるもの」と見なしている工程です。

セットアップを行うと、検証用のスキルがコーディングエージェントに組み込まれます。そのため、あなたが結果を伝えるのを待つのではなく、エージェント自身が証跡を生成し、読み取れるようになります。断続的に発生する不具合であれば、同じケースを繰り返し実行することで発生率が得られ、新たな仮説を立てるよりもはるかに早く原因を絞り込めます。

しかも、再現手順は修正後も残ります。プロジェクト内に残り、変更のたびに実行されるため、ブランチがマージされてやり取りが失われた後に、同じ不具合が知らないうちに再発することはありません。