テスト駆動開発を学ぶ

第4章. 懸念の分離

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

「懸念の分離」とは......私が言うところの「ある側面に注意を集中すること」である。それは他の側面を無視することを意味するのではなく、この側面から見れば他の側面は無関係であるという事実を正当に評価することである。それは、一本道であると同時に多本道であるということである。

エドガー・ダイクストラ「科学的思考の役割について

ソースコードが増えた。 言語にもよるが、1つのソースファイルで50〜75行になる。これは、多くのディスプレイ・モニターでは画面一杯に表示され、本書では印刷されたページよりも多い。

次の機能に取りかかる前に、コードのリファクタリングに時間を費やそう。それがこの章と次の3つの章の主題だ。

テスト・コードとプロダクション・コード

ここまで、我々は2つの異なるタイプのコードを書いてきた。

1. マネー問題を解決するコード。これにはMoney 、Portfolio 、そしてそこに含まれるすべての振る舞いが含まれる。これをプロダクション・コードと呼ぶ。

2. 問題が正しく解決されたことを検証するコード。これには、すべてのテストと、これらのテストをサポートするために必要なコードが含まれる。私たちはこれをテストコードと呼んでいる。

この2つのタイプのコードには共通点がある：同じ言語であること、（今ではおなじみとなったレッド-グリーン-リファクタリングのサイクルを経て）連続して書くこと、そして両方をコード・リポジトリにコミットすることだ。しかし、2種類のコードにはいくつかの重要な違いがある。

一方向依存

テストコードは実運用コードに、少なくとも実運用コードのテストする部分に依存しなければならない。 しかし、逆方向の依存関係はあってはならない。

現在、図4-1に示すように、各言語のコードはすべて1つのファイルになっている。そのため、本番コードからテストコードへの偶発的な依存関係がないことを保証するのは容易ではない。テストコードから本番コードへの暗黙の依存関係がある。これにはいくつかの意味がある：

1. コードを書くときには、本番コードに誤ってテストコードを使わないように注意しなければならない。

2. コードを読み取る際には、使用パターンを認識し、また、欠落しているパターン、つまり、本番コードがテストコードを呼び出せないという事実にも気づかなければならない。

図4-1. テストコードと本番コードが同じモジュールにある場合、前者から後者への依存関係は暗黙的である。

重要

テスト・コードはプロダクション・コードに依存するが、逆方向の依存はあってはならない。

本番コードがテストコードに依存している場合、どのような悪い結果が考えられるだろうか？ 特に悪いケースでは、テストされたコード・パスが "原始的 "であるのに対して、テストされな かったパスにはバグが多いというような誤解を招く可能性がある。図4-2は、自動車のエンジン制御ユニットの擬似コードの一部である。このコードは、エンジンが排ガス規制を遵守するためにテストされる場合と、エンジンが "現実世界 "で使用される場合とで動作が異なる。