導入

テスト駆動開発は、十分にテストされ、リファクタリング可能なコードを確保するための効果的な方法です。基本的な考え方は、テストを書くことから開発を始めるということです。これらのテストは期待値を明確に文書化し、実装を成功させるためのルーブリックを作成します。適切に実行すると、コードを記述する前に関数の予想される入出力を明確に定義できます。これにはすぐにいくつかの利点があります:

• コードを操作するためのインターフェイスを慎重に検討し、テストしやすいように設計します
• コードの作成を開始しても、手動テストや結果を予測するための実行ロジックのステップ実行によってフローが中断されることはありません。代わりに、テストを実行するだけです
• テストに合格することは、達成することで満足のいく目標になります。プロセスを明確に定義された達成可能な一連のマイルストーンに分割すると、仕事がより楽しくなります
• コードのテストを妨げる可能性のある実装後の怠惰や自信過剰を避けてください

メリットを理解できたので、次の手順に従ってテスト駆動開発 (TDD) を開始できます。

1. テストの作成または変更
2. テストが失敗したかどうかを確認する
3. テストに合格するために最小限のコードを記述します

これらのステップはサイクルで実行されるため、常にテストを追加して現在の実装に挑戦することになります。

最後のステップでは、最小限のコードを記述することが指定されていますが、厳密に従うと作業が退屈になる可能性があります。いつこのルールから逸脱するのが適切かを判断する前に、このルールが存在する理由を理解することが重要です。

簡単な例

あなたには関数 Add(x, y int) int を実装するという使命があります。実装にジャンプして単に x y を返す前に、最も単純なテスト 1 1 == 2 を作成します。それでは、テストに合格する最も単純な実装は何でしょうか?単に return 2 です。これでテストは成功しました!

この時点で、さらにテストが必要であることがわかり、ペースを上げてさらにいくつかテストを追加します。

• 1 2 == 3
• 100 5 == 105

テストが失敗するので、実装を修正する必要があります。今回は単に 3 を返すことも 105 を返すこともできないため、すべてのテストに有効な解決策を見つける必要があります。これにより、return x y.

これは単純な例では過度に退屈に感じられますが、この方法を厳密に遵守すると、実装を信頼するだけでなく複数のテストを作成することになります。もちろん、x y を返すという最初のアイデアはうまくいきましたが、重要なのは、コードについての自分自身の理解ではなく、テストに依存するように自分自身を再訓練することです。現実の世界では、このコード部分に取り組んでいるのはあなただけではないため、必然的に実装の詳細を忘れてしまいます。このプロセスでは、より多くのテストを作成し、単純な実装を壊すためのより多くの方法を考える必要があります。

最終的には経験を積み、遭遇するさまざまなシナリオで機能するバランスを見つけることを学びます。機能のフルスピード実装に戻り、バグが減り、より保守しやすいコードを作成できることがわかります。

HTTP API の段階的な TDD

HTTP REST API に TDD を使用した、より複雑な例を見てみましょう。このステップバイステップ ガイドでは、私の Go フレームワークである babyapi を使用していますが、この概念はどこにでも適用できます。

babyapi はジェネリックスを使用して Go 構造体を中心とした完全な CRUD API を作成し、完全な REST API とクライアント CLI を非常に簡単に作成できるようにします。これに加えて、babytest パッケージは、エンドツーエンドの API テーブル テストを作成するためのいくつかのツールを提供します。 API レベルで TDD を使用すると、新しい API または機能の HTTP 層とストレージ層を一度に完全にテストできます。

免責事項: babyapi は実装の大部分を処理し、テスト定型文の生成にも使用されるため、技術的には TDD から始めているわけではありません。ただし、API に PATCH リクエストのサポートを追加すると、それがどれほど有益であるかがわかります。

1. 新しい Go プロジェクトを作成する
   

2. babyapi の簡単な例を使用して初期の main.go を作成します
   

3. CLI を使用してテスト ボイラープレートを生成
   

4. プレースホルダーに予想される JSON を入力して各テストを実装します
   

5. テストを実行して、テストが成功することを確認してください。

6. PUT は冪等であるため、すべてのフィールドを含める必要があります。これを回避するために、PATCH リクエストで完了を切り替えるサポートを追加したいと考えています。まず、この機能がどのようになるかを予想する簡単なテストを追加します
   

7. babyapi はデフォルトで PATCH をサポートしていないため、このテストは失敗します。 TODO 構造体に Patch を実装することで修正できます。 2 つのテストで機能を定義したため、最も単純な実装では Completed = true を設定するだけではなく、request
   の値を使用する必要があります。

8. TODO の完了ステータスを変更できるようになりましたが、この新しいテスト セットで示されているように、PATCH を使用して他のフィールドを変更することはまだできません
   

9. パッチを更新して残りのフィールドを設定します
   

10. リクエスト フィールドが空であっても常に TODO を更新するため、テストは依然として失敗します。空の値をチェックするように実装を更新してこの問題を修正します
    

11. 新しい UpdateWithPatch テストは合格しますが、以前のテストは失敗します。 Completed を *bool に変更したため、空の値で作成された TODO は null
    として表示されます。

12. Render for TODO を実装して、nil を false として扱えるようにします
    

テスト駆動開発で PATCH 機能を実装すると、堅牢なテストのセットと適切に実装された機能が得られました。テストでは PATCH リクエストの予期される入力と出力を定義することから始めたので、リクエスト内の空の値をチェックしないことによって引き起こされる問題は簡単にわかりました。また、既存のテストでは、Completed のタイプを *bool.

結論

テスト駆動開発は、完全にテストされた正しいコードを作成するための効果的なアプローチです。テストを念頭に置いて始めることで、テストを後回しにするのではなく、すべてのコードがテスト可能になるように設計されるようになります。

TDD の採用に迷っている場合は、始めるためのアイデアをいくつか紹介します。

• 関数の入出力が明確で、実装がそれほど複雑ではない単純なシナリオで試してください。発生する可能性のあるさまざまな入出力に対して堅牢なテーブル テストを作成できます。さまざまなシナリオを明確に視覚化すると、実装が簡素化されます
• 新しいバグを修正している場合は、テストのギャップがすでに特定されています。まず、このバグを特定するテストを作成することから始めます。次に、既存のテストを中断することなく、このテストを通過させます。
• babyapi の例と同様に、高レベルの API テストに TDD を使用できます。予想されるリクエスト/レスポンスを定義したら、実装のより詳細な部分に向けて通常の開発フローを再開できます

TDD がコードの書き方に適していない場合でも、常に身に付けておくべき強力なツールです。少なくとも時間をかけて試してみて、それが開発プロセスにどのような影響を与えるかを確認することをお勧めします。