誰もがテスト駆動開発について語っていますが、実際に実践している人はいるのでしょうか？
TDDは、ソーシャルメディアやテクノロジーカンファレンスのパネルディスカッションで、開発者の間でアジャイル開発の「ベストプラクティス」として数年前から広く受け入れられてきました。しかし、DiffblueのCEOであり、PythonベンダーAnacondaの元SVPでもあるマシュー・ロッジ氏との会話の中で、こうした議論が実際に実践されているのかどうか疑問に思い始めました。
DiffblueはAIを活用してJavaユニットテストの作成を自動化します。理想の世界では、DiffblueのCover（無料お試し版あり）がTDDを補完するために使用されるはずですが、現実はそうではありません。その理由を説明しましょう。
テストの理論と実践
TDDは理論上は素晴らしいように聞こえます。最も純粋な形では、開発者はまず失敗するように設計されたテストを書き、その後コードを書きます。つまり、テストはコードが何をすべきかを表現するものであり、その後、テストに合格するようにコードを書くという考え方です。
これは通常、最小限の要件から始めてテストを記述し、コードを記述し、その後、テストとコードの要件を少しずつ拡張および改良していくという反復的なプロセスになります。新しい障害モードが発見されたり、新しい機能が必要になったりしたときに、コードをリファクタリングします。
参照: 採用キット: バックエンド開発者 (TechRepublic Premium)
現実世界では、コードが何をすべきかを完全かつ完璧に記述する人はいないとロッジ氏は述べた。定義上、アジャイルコンピューティングとは反復、つまり望ましい結果を達成するための段階的かつ頻繁なコード改善のことだ。一般的に、誰も事前にコードの動作を正確に把握していないため、賢明な開発者はCircleCI、GoCD、Travis CIなどの継続的インテグレーションおよび継続的デリバリーパイプラインにコミットする前にテストを作成する。
さらに、開発者はまだAPIを書いていないため、そのAPIが何なのかも知りません。実装がAPIに情報を提供するのですが、そもそも最初からAPIを正しく実装するのがいかに難しいかは、すべての開発者が知っています。では、開発者はどのようにして最初にテストを書くのでしょうか？
これは、Co-Pilotのような新興のAIコード生成ツールと似ています。まるで魔法のように使えるコードが生成されるのを見て、人々はまず驚きます。しかし、実稼働環境になると、優秀な開発者でもCo-Pilotで生成されるコードの30%しか得られず、大部分は依然として手作業で記述しなければなりません。なぜでしょうか？複雑なソフトウェアを事前に完全に正確に記述できる人はいないからです。
しかし、今回のケースでは、開発者にとってそれは大きな改善です。Co-Pilotが最終コードを100%生成できなかったからといって、それが失敗したわけではありません。これは進歩です。開発者の時間を節約できるものはすべて良いことです。
しかし、ロッジ氏と話をしていると、TDDはこの基本的なテストに合格していないように思えます。グリーンフィールドコードでは、TDDは理にかなっている場合もありますが、実際の本番環境で普遍的なベストプラクティスとして採用するのは非常に困難です。
参照: 採用キット: Python 開発者 (TechRepublic Premium)
ロッジ氏によると、Diffblue は 2020 年に企業開発者を対象にした無関係の調査でこの小さな汚い秘密を発見したという。
TDD は人気があるものの、それを実践している企業はわずかです。2020 年 9 月に公開された開発者調査によると、回答者の 41% が組織で TDD を完全に導入していると回答したものの、TDD の定義である、少なくとも 80% の時間でコードの前にテストを記述していると回答したのはわずか 8% でした。
テストを書くかコードを先に書くかという選択肢を与えられた場合、開発者は、たとえ優れた実践者が何を言おうと、ほぼ常に後者を選ぶようです。開発者は議論好きで、自分の主張を擁護する素敵な人たちですが、結局のところ、優れた開発者は現実的です。彼らは物事を成し遂げることにこだわるのです。TDDは死んではいませんが、私たちが時々考えるほど「生きている」わけではないのかもしれません。
開示: 私は MongoDB で働いていますが、ここで表明されている意見は私自身のものです。
