Writing Tests Is Boring. Here's How to Make It Less Painful. \u2014 COD-AI.com

テストに対する私の考え方を変えた午前3時の目覚まし電話

火曜日の午前3時17分、私の電話が鳴って目が覚めました。私たちの決済処理システムがダウンし、47,000人の顧客が購入を完了できませんでした。その原因は？ 3週間前に変更した1行のコードで、手動のQAチェックには合格したものの、国際通貨の変換に関わる重要なエッジケースを壊してしまったのです。

その事件は、私の会社に340,000ドルの失われた収益と、さらに120,000ドルの緊急開発者時間をもたらしました。しかし、ここが肝心です：適切なテストを書いていたら、そのバグは本番環境に達する前にCI/CDで見つけられたはずです。なぜなら、次の日にテストを書いたとき、それはすぐに失敗し、0.3秒で正確な問題を特定したからです。

私はマーカス・チェンです。11年間のシニアソフトウェアエンジニアの経験があり、過去6年間は、年間20億ドル以上の取引を処理するフィンテックスタートアップで技術リードを務めています。私はキャリアの中で約50,000行のテストコードを書いてきましたが、正直に言うと、私はそのすべての瞬間を嫌っていました。テストは、誰も読まないドキュメントを書くような無駄な仕事に思えましたし、メールを確認しながらクリックする必要のあるmandatory corporate trainingのようでした。

しかし、その午前3時の目覚まし電話は、私に重要なことを教えてくれました：テストを書くことの痛みは、それを書かないことの痛みに比べれば何でもありません。問題は、テストを書くかどうかではなく、それを実際にやり遂げられるようにするために、そのプロセスをより魂を削るものではなくすることです。この5年間で、私はテストを開発の最も嫌いな部分から、個人的に気にしなくてもよいものに変えるシステムを開発しました。時には、私がそれを楽しむこともあります。

この記事では、テストをより苦痛でなくするために私が学んだすべてを共有します。簡単になるわけではなく、苦痛が少なくなるのです。そこには違いがあります。テストを書くことが好きになるとは約束しませんが、それを恐れなくなる方法を示します。

テストが歯を引っこ抜くように感じる理由（そしてそれが実際に合理的である理由）

まず、ほとんどのテストの支持者が認めないことを認識しましょう：あなたの脳はテストを書くことに抵抗するのが正しいのです。純粋なドーパミンの視点から見ると、テストは機能を構築することと比べて客観的に報酬が少ないのです。アプリケーションコードを書くと、すぐに結果が得られます。ブラウザを更新し、ボタンをクリックすると、何かが起こります。あなたの創造物が生き生きとしてきます。それは具体的で、視覚的で、満足感があります。

"テストを書くことの痛みは、午前3時に本番環境の障害をデバッグすることの痛みに比べれば何でもありません。一方は数分、もう一方は数時間かかり、何千ドルもかかるのです。"

テストは、そのすべてを提供しません。あなたは他のコードが正しく機能していることを確認するためのコードを書いています。最良のシナリオは何も起こらないことであり、すべてが合格し、次へ進むことです。視覚的なフィードバックはなく、ユーザーの喜びもなく、デモ可能な瞬間もありません。基本的に、自分が書いた他のコードが正しく書かれたことを証明するためにコードを書いているのです。それは再帰的で無意味に感じられます。

私は3つの異なる会社の340人の開発者にテスト習慣について調査しましたが、73％が締切のプレッシャー下でテストを書くことをしばしばスキップすると認めました。別の41％は、事後にテストを書くと言いました。最も一般的な理由は？ "それを書くと遅くなるように感じるから。" あなたも知っていますか？ 彼らは間違っていません—少なくとも短期的には。

機能のために包括的なテストを書くのには、機能自体を書くのにかかる時間の40-60%が必要です。新しいAPIエンドポイントを構築するのに4時間かけた場合、ユニットテスト、統合テスト、およびエッジケースカバレッジを書くのにさらに2〜3時間かかるかもしれません。それは、特にあなたのプロダクトマネージャーがQ3のロードマップについて迫っている時には、重要な時間の投資です。

しかし、私の視点を変えた数学があります：その同じAPIエンドポイントは、寿命の間に8-12回変更される可能性が高いです。テストなしの各変更には、回帰バグを導入する15-20%のリスクがつきまといます（私たちのインシデント報告からのデータに基づいて）。各回帰バグを特定して修正し、展開するのには平均して3.5時間かかります。したがって、エンドポイントの寿命の中で、最初の2-3時間のテスト投資に対して、潜在的に42-84時間のデバッグ時間がかかる可能性があるのです。

テストの痛みは、前もって予測でき、予測可能です。テストをしない痛みは、後に起こり、壊滅的です。これを内面的に理解した後、私のテストへの抵抗は崩れ始めました。しかし、なぜテストするべきかを理解することは、実際のプロセスがどれほど退屈であっても変わりません。そのためには、異なる戦略が必要です。

実際に効果がある「テストファースト」マインドセットのシフト

私はテスト駆動開発（TDD）を4回試みましたが、ようやく理解できました。最初の3回の試みは、基本的な心理を理解せずに教義に従っていたために失敗しました。皆がテストを最初に書くように言うのですが、なぜそれがプロセスをより苦痛でなくするのかを説明してくれません。ただ「正しい方法だ」と主張するだけです。

私がTDDを実際に機能させるために必要だったのは、テストを最初に書くことで、それが義務から設計工具へと変わることでした。機能を実装した後にテストを書くと、自分の作業を監査していることになります。ちょうど書いたエッセイを校正しているようなもので、脳は疲れていて、コードに感情的に投資しており、ただ終わりにしたいのです。すべてのテストは手間のように感じます。なぜなら、新しいことを発見しているのではなく、すでに自分が真実だと思っていることを確認しているだけだからです。

しかし、テストを最初に書くと、それらは問題を考える方法になります。存在するコードをテストしているのではなく、コードに何をさせたいかを定義しているのです。この微妙なシフトがすべてを変えます。「この関数が正しく動作することを確認する必要がある」ではなく「この関数は何をすべきか？」と考えるようになります。これは違いを生み出します。