TDD を教えるときに伝えるべき最も重要なことは 1 つあります [終了]

Question

私は専門家のグループと協力して、興味はあるが経験がない人 (初心者) に TDD の実践を教えるイベントを開催しています。

私たちはラボやワークショップなどを考え出そうとしていますが、私はこれらの人々が今後 TDD を実践して成功できるよう、彼らに伝えなければならない唯一かつ最大のことを考えようとしています。

学習において何を優先すべきだと思いますか?TDD 教育のどの側面について の 最も重要な。2 つのことをしなければならない場合でも、それは問題ありません。1 つの部分に固執するつもりはありません :)

Answer 1

デザインの話です. 。その ない テストについて。

Answer 2

プロセスのステップをスキップしないでください。TDD の最初の溝に入るまでには時間がかかりますが、いったん導入されると、SDLC 全体がより高速になり、バグがはるかに少なくなります。

赤 - 緑 - リファクタリング -> 実行するだけです。

Answer 3

テストに合格したからといって、コードが正しいとは限りません。

それはさておき、設計の中でテストを考慮することが重要だと思います。テスト対象ユニットの内部実装についての詳しい知識がなければコードをテストするのが難しい場合は、設計を再検討する必要があるかもしれません。そうしないと、コードに合わせてテストを変更する必要が生じる可能性が高いため、リファクタリングはよりリスクが高くなります。

Answer 4

これが最も重要なこととして数えられるかどうかはわかりませんが、私が初めて TDD の使用を検討していたとき、これを「理解する」のに時間がかかったことでした。

テストを書く前に頭の中でコードを書かないでください。

初めて TDD を始めたとき、私は設計がどうあるべきかを「知っていました」。私は自分が書きたいコードを「知っていました」。そこで、その部分のコードを記述できるテストを書きました。

これをやっていたときは、実際には TDD をやっていませんでした。最初にコードを書いていたからです (たとえコードが頭の中にあっただけだったとしても :-)

テストに集中する必要があることに気づくまでには、少し時間がかかりました (賢い人たちからの指摘もありました)。必要な動作を実現するためのテストを作成し、それを通過させるために必要な最小限のコードを作成し、リファクタリングを通じて設計を実現します。完了するまで繰り返します。

Answer 5

「忍耐強く」を提案します。最初は奇妙に感じます。私にとって、それが自然に感じられるようになるまで、おそらく 3 つのプロジェクトが必要でした。

Answer 6

何に同意するか ジョンは答えの中でこう言った, しかし、重要な帰結は、テスト容易性が決定するものではないということだと思います。 「良いデザイン」, ただし、これはデザインが目標を達成していることを示す指標にすぎません。

Answer 7

私の考えでは、TDD はリズム (赤、緑、リファクタリング) がすべてです。リズムを整えることで、「理解できない」という「困難」を乗り越えることができます。そして、リズムを掴まなければ、TDD を長く続けることはできないでしょう。リズムの本質はすでに述べたベイビーステップです。できる限り少ないコードを記述し、容赦なくリファクタリングします。

一つのこと 強調する TDD は短期的な利益を長期的な利益と引き換えにしているということです。TDD を使い始めると、必ず生産性が低下します。しかし、一度リズムを覚えてしまえば、調子に乗るようなもので、実際に作業が早くなるのに役立ちます。TDD の副作用として、回帰テストを提供する単体テストのベースが増え続けていることは言うまでもありません。ソフトウェアの必然性の 1 つは、保守中のシステム (一連の自動回帰テストなし) が時間の経過とともに劣化することです。

Answer 8

TDD は開発者にとってのパラダイムシフトであることを強調するs.新しいチームを立ち上げる場合は、チームが TDD 実践者として完全に機能するまでに最大 6 か月かかることを認識してください。成熟したアジャイル チームが効果的に TDD を実践できるようになると、ペアリングを行うことで、新しい開発者は数回繰り返した後に本格的に取り組むことができるようになります。さらに、1 つのチームのペアを使用して新しいラインをシードすることにより、最初のラインよりもはるかに速く新しいラインを TDD で高速化することができます。

私たちが測定したプロジェクトでは、チームが TDD の方法を学習すると、自動化された機能/回帰テスト中に見つかる欠陥が 6 分の 1 に減少することがわかりました。これは大幅な節約になります。さらに、このコードは、各機能のコード行が減り、よりクリーンな設計を反映しています。TDD ですが、金メッキは実質的に停止されます。TDD は、ストーリー カードに受け入れ基準がある場合に最も効果的です。

TDD は持続可能なペースも可能にします。チームは、コードがほとんど欠陥がなくクリーンなままであるため、各反復で同じ数の機能を実行し続けることができることがわかります。TDD と自動化された機能/回帰テストの両方で、ユーザー受け入れテスト中に欠陥が検出されないことがよくあります。

Answer 9

締め切りが迫っているときに TDD を放棄するというプレッシャーに対処する。これは、私が TDD で人々やチームを支援する中で遭遇した最大の問題の 1 つです。彼らは、テストの代わりに特集を組むことの重要性と価値を上層部に伝えるのに苦労していました。

Answer 10

赤ちゃんの一歩ずつ進んでください。

PhlipCPP が言うように、テストは非常に狭い範囲のみをカバーするようにしてください。'テストに合格するために必要な最小限の編集を実行します。'

それでも、TDD にはやるべきことがたくさんあるので、何も見逃さないようにする必要があります。

Answer 11

私の経験では、TDD を使用すると、私と私のチームは、予期しない場所で何かが壊れるのではないかと心配することなく、容赦なくコードをリファクタリングできます。

したがって、私にとって TDD の最も重要な側面はカバレッジだと思います。カバレッジが良好であれば、コードベース内でそれを使用できる箇所を見つけたときにいつでも、自信を持ってリファクタリングできるからです。

Answer 12

さまざまな種類のテストを強調します。ブラックボックス テストとホワイトボックス テストはどちらも重要であり、目的が異なります。ホワイトボックス テストはシステム全体をテストできないため、正確性を検証するためにはありません。これは、コードの臭いをさらに強くし、より良いリファクタリングの方向性を提供するためにあります。ブラックボックス テストは、正確性をテストするためにあります。すべての機能をブラックボックス テストする必要があります。

また、テスト範囲の違いも強調します。組み合わせと再現性の問題により、アプリケーション内のすべてのコード パスをブラックボックス テストすることは不可能です。私のルールは、機能はブラックボックス テストされるまで完成しない、というものです。生徒が自分自身のルールを見つけられるよう支援する必要があります。ただし、ホワイトボックス テストには外部クラスの依存関係があってはなりません。したがって、すべてのクラスのすべての行をホワイトボックス テストする必要があります。