Clever Geek Handbook

TDDと単体テストについてもう少し

ハブにはTDDの支持者が多く、テスト方法による開発に関する記事は繰り返し掲載されています。 5つのコペックをこのすばらしいツールに関する記事にしたいと思います。



初心者がテストを見ると、疑問がすぐに生じます。なぜ余分なコードを書くのが面倒なのでしょうか？ TDDの利点を否定している人はいないように見えますが、いくつかの理由があります。「はい、TDDは大規模なプロジェクトで役立つと聞きましたが、小さなプロジェクトがある」など。 単体テストが仕事でどのように役立つかを伝え、経験を共有しようと思います。





1.簡素化されたコードサポート



TDDはリファクタリングと連動します。これは、赤緑リファクタリングのイデオロギーに組み込まれているため、テストを使用する最も明白な理由です。 プログラムコードは、他のシステムと同様に、独自のライフサイクルを持っています。メンテナンス、修正、改善が必要です。そうでなければ遅かれ早かれ崩壊し、「すべてが非常に悪い、すべてを書き換える必要があります」状態になります。 原則として、これは、明確な目的を失い、変更の結果がいつどのように明確にならないかわからないコードを理解するのが非常に難しいと感じるプログラマーの心理的反応です。 テストを作成する必要があります（長くて退屈で、「最初にテスト、次にコード」の原則に対応しなくなります）、ためらいなくテストを行うことをためらいがちです（多くのエラーが発生します）。 私は自分で悪いコードを自分で捨てることが好きでしたが、今では動作時間を捨てるよりもテストなしでリファクタリングを開始する方が良いと思います-エラーが少なくなります。 可能であれば、テストを作成します。 リファクタリングツールキットは強力であり、遅かれ早かれコードの一部が消化しやすい外観になり始めます。 ダークサイドに屈しないでください...

テストを間違えたり、テストをスキップしたりすることがよくあるため、テストの作成はお勧めしません。 私は普遍的な方法を見ていません。



2.構造をモジュールに明確に分割する



原則として、TDDの使用を開始した人は、コンパクトなテストを作成するために、モジュールは十分に説明されたインターフェイスを持っている必要があることを既に理解しています。 コードを変更すると、入力データと出力データは変更されず、すべて問題ありません。

ここでの問題は、インターフェースが変更されたときに始まります。 これは、すべてのコードのかなりの割合を占める可能性があるテストの書き換えにつながるものです。 どこにでもストローを置くことはできません。時にはテストを変更する必要があります。 これは、順番に、テストコードもリファクタリングする必要があるという事実につながります。ここで、一部の人々はすでにテストのためにテストを書き始めています。

問題は複雑で、明確な解決策はありません。 この問題を解決する兄弟プログラマーは、システム開発の経験と戦略的ビジョンを支援します。



3.複雑さとの戦い



McConnell、Brooks、および他の人々のような善良な人々は、彼らの意見では、ソフトウェアの問題-複雑さについて書いています。 複雑さは、コードの量に比例して大きくなります。 プログラマーがすべての要件を頭にダウンロードできれば、おそらくこのような問題は存在しないでしょう。 しかし、残念ながら、私たちのリソースは限られています。 人類はこれに対処する優れた方法を思い付きました-階層の導入：メソッドはクラス、パッケージのクラス、ライブラリのパッケージにカプセル化されます。 これらのうち、より複雑なアプリケーションはブリックから構築されます。 しかし、アルゴリズムの記述が単に脳を破壊し、それが完全に堅固な場合はどうでしょうか？ たぶん私はばかげているかもしれませんが、一部のアルゴリズムは時々私を困惑させます。 ある時点で、すべてのコード要件が単に脳に適合しない。 そのような場合、テストは私にとって唯一の救いです：ソースコードの増加にもかかわらず（そしてしばしば小さな見かけのアルゴリズムには多くの行動シナリオがあるので何度も）、将来の回帰エラーが少ないため時間は節約されます。 特にフィードバックが長い間間違えられている場合。 心理的な側面も重要な役割を果たします。TDDマントラを少し繰り返して、コードのこの嫌なセクションを理解してください。

ただし、テストは万能薬ではなく、テストで100％をカバーしたいという要望に対して多くの人が警告しています（この場合、開発環境で生成されたコードはどうなりますか？その他の不快な結果）。 コードが単純な場合、テストを記述すると、結果として何も提供せずにソリューションの複雑さが増し、それに応じて価値が追加されません。 複雑さを評価する方法は？ よくわからないが、時には私の内なる声から、テストなしではできないと言われる。

開発者の目標は、コードを100％テストまたは正確に5％で熱狂的にカバーすることではなく、複雑なソリューションを作成し、開発時間と品質、テストの可用性とテストの欠如をバランスさせることです。 私の貯金箱では、プロジェクトは約0から20％のテストでカバーされており、プロジェクトのパラメーター（チームの人数、開発期間、またはシャッフル）に明確な依存関係がありません。 すぐに、1つのチームの人数が3人を超えないように予約します（小規模なチームで作業します）。1つのプロジェクトの期間が2,000人時の開発時間を超えないようにします。



4.仕様としてのテスト



アルゴリズムと作業シナリオの説明を表示できる技術的なタスクがあります。 テストから何を得ることができますか？ TKはエンドユーザー側で望ましい結果を記述し、プログラマーはコメント、コードデザインルール（スピーキングメソッド名など）、および場合によってはテストを使用して、アプリケーションを作成するときのソリューションのビジョンを説明します。 テストでは、プログラマーが希望する動作を表示できます。これは、unningなアイデア、一時的な措置、またはずさんなものなど、そこに埋もれているものを理解することが困難な場合にサポートで役立ちます。 当然、これは万能薬でもありません。「逃したテスト」などの汚いトリックから私たちを守るものは何もありません。

1つのプロジェクトでテストを作成し、最初の目標は仕様です。 〜100個のプラグインのソリューションがあり、それぞれがシンプルでエレガントですが、それらはすべて、バーベキューの肉のようなメインシステムのシステムコールに縛られており、頻繁な注意が必要です：顧客はしばしばビジネスプロセスを変更するか、より効果的な使用方法。 必要に応じて、変更のリスクと開発時間を迅速に評価するために、モジュールの動物園を厳重に管理する必要があります。



5.心理学



私はすでに上記の心理的な側面について書きました、もう一度強調したいです。 TDDはまた、反復の原則をソースコードでの作業レベルにもたらします。つまり、新しい変更の計画-変更の作成-変更の最終決定（別名、レッドグリーンリファクタリング）です。 アルゴリズム/チャート/ダイアグラムの研究から脱却し、小さな一歩を踏み出すために自分自身を圧倒する素晴らしい方法。 その後、再び戻ってすべてを繰り返します。

通常の滝はここで失われることはありません。アルゴリズムが一度にすべて適合する場合、反復する必要はありません。 そうでない場合は、他の方法を試してください。

さらに、テストにより、コードに自信を持ち、「作業-触らない」という原則を取り除くことができます。 負の変更はすぐに反映されます。



おわりに



これらの目標はすべて互いに非常に近いものであり、そのうちの1つにTDDを使用すると、これらすべての利点と欠点が得られます。 余分なツールは誰も傷つけません。それを使用する決定は開発者（またはチーム全体）にかかっています。 良いコードを書いてください、そしてフォースがあなたと一緒にいるかもしれません！



habrには既に：



More articles:


All Articles