私は同僚に単体テスト（およびテスト全般）の概念を紹介したいと思います。現在、テストはまったく行われておらず、実際にUIを介してタスクを実行して目的の結果を確認することにより、テストが行​​われています。ご想像のとおり、コードは正確な実装と非常に緊密に結合されています。クラス内にあり、システム全体で再利用されるコードがメソッド間でコピーおよび貼り付けされることさえあります。

要件が変更されたため、以前に書いたモジュールを修正するように依頼されましたが、それはかなり疎結合です（希望するほど多くはありませんが、他の多くの概念を導入することなく取得できます）。修正されたコードに単体テストのスイートを含めて、期待どおりに機能することを「証明」し、テストの仕組みを実証することにしました。コードの一部はすでに記述されているため、真のTDDをフォローしていませんが、作成する必要がある新しいコードについては、TDDの概念に従うことを望んでいます。

今、どうしてコードを書くのに1日か2日以上かかるのかと聞かれるのは避けられないだろう、なぜなら私がやり取りすることの一部はすでにシステムに存在しているからだ））でコードをチェックすると、この「テスト」プロジェクトとは何かを尋ねられます。テストの基本を説明することはできますが、他の人が理解する方法で実際の利点を説明することはできません（テストは自分でアプリを実行する必要があると考えているためです。 " か否か）。彼らは疎結合の概念を理解していません（疎結合されたものは何もないという事実から明らかです。私が書いたコード以外のインターフェースすらありません）。それを利益として使用しようとすると、おそらく「ハァッ」を得るでしょう。ある種の見た目であり、既存のいくつかのモジュールを作り直さずに、おそらく「プログラミング」ではなく時間の浪費と見なされるIoCコンテナを導入することなく、やりたいほどゆるくすることはできません。

誰も私がこのコードを指す方法についての提案を持っていますか？私のものが悪いことを除いて）またはそれは時間の無駄のように見えることなく、実際の価値を追加しませんか？

同僚に単体テスト（および一般的なテスト）の概念を紹介したい

概念的な側面ではなく、実用的な側面から始める方が良いと思います。もちろん、カジュアルディスカッションで同僚や管理職が単体テストについて興味を持っていることに気付いた場合は、ウェブから具体的な経験や証拠をグーグルアップし、簡単なトレーニングなどをまとめることができます。しかし、あなたが説明することから、あなたのチームメイトはこの奇​​妙な新しいアイデアにあまり開かれていないようです。

このような状況では、私は最初にあまりにも多くのことを説明しようとせずに、私の小さな単体テストを書き始めます。すべてのコードを徹底的にカバーしようとせずに、コードを変更するたびにそれらをいくつか追加します（これには膨大な時間がかかります）。理想的には、うまくバランスが取れていれば、ユニットテストを書いていることに気付くまでに、すでにかなりのテストスイートといくつかの具体的な結果が得られている可能性があります（「このテストケースではバグをキャッチできた先週の変更で導入されました。そうでなければ、QA /プロダクションにすり抜けていただろう」それは、真面目な開発者にとってテストの価値を証明します。

その後、次のような単体テストの長期的な利点について説明し始めることができます。

• コードがいつでも、どこでも、即座に、そして自動的に機能することを証明します。
• リファクタリングに自信を与え、設計の改善と保守性の向上をもたらします。
• また、何かが壊れた場合、バグが別のQA部門で検出された場合の数日または数週間の待機時間とは対照的に、単体テストは（ほぼ）即時のフィードバックを提供します。これにより、通常、短期間のメモリから削除されてから長い時間を経てコードをデバッグする代わりに、数秒でバグを修正できます。

関連するスレッド：自動化された単体テスト、統合テスト、または受け入れテストも参照してください。

そして、SOからの以前のもの：ユニットテストとは何ですか？

恐れのないリファクタリング

わずかに異なる角度として、TDDでは「恐れることなくリファクタリング」できます。これは、チームを売ることができる重要な利点です。開発者が自分で言うことを止めます：

• 「私はそれを壊すのが怖いので、このコードには触れたくない」
• 「どのように機能するかわからないので、このコードに新しい機能を書きたくありません」
• 「秘密に、私はそのコードが怖い」

もっとハープできますが、TDDのボブおじさんやTDDのマーティンファウラーのように、よくカバーされています。

依存関係

ああ、もう1つ追加します。TDDがどのように優れたデザインを強制し、依存関係をきれいに処理できるかを示します。

ボブ：「ああ、c％^ p！ボスは私たち全員にMS SQL Server 2008の使用を強制しました」私たちはその道を進みます。」

自動化されたテストを行わないソースコードに取り組んでいる間、私たちが行っている種類の変更が既存の機能を壊さないことを確信するために、私たちは細心の注意を払って作業し、より多くのレビューが必要です。

優れた自動化されたテストケースがある場合、結果はより速く、自信があり、恐れのない開発になります（バグの修正、強化、またはリファクタリングが可能です）。

計算する

• t _mt =影響を与える可能性のあるすべてを手動でテストするのに必要な時間
• t _wt =テストの作成に必要な時間

• k =新しいコードをリリースする前におそらくすべてをテストする必要がある回数

  （t _wt <t _mt）または（t _wt <（k * t _mt））ならば、それは簡単です：テストを書くと開発がスピードアップします。

それ以外の場合は、比率（t _wt /（k * t _mt））を確認します。非常に大きい場合は、別の機会を待ちます。それ以外の場合は、回帰テストの利点を正当化します。

注：この時点では、ユニットではなく機能のみをテストすることをお勧めします。正当化と理解がはるかに簡単で、リファクタリング時に単なるユニットテストよりも価値の高い作業が間違いなく少なくなります。

注2：テストは自動化されているため、テストの実行にかかる時間は重要ではありません。テストの実行に時間がかかりすぎて締め切りに間に合わない場合を除き、テストの実行中に他の生産性の高い操作を行うことができます。これはまれです。

マイクロソフトショップの場合の提案：ベストプラクティスとしてユニットテストまたは疎結合を推奨しているいくつかのドキュメントをMSDNで見つけ（これの複数のインスタンスがあると確信しています）、競合がある場合はそれを指摘します。

それは物事を行うための粗雑な方法のように聞こえるかもしれませんが、私は「ベストプラクティス」という用語を使用すると、特に管理の場合に長い道のりがかかることを発見しました。

私がいつもお勧めするように、素晴らしいプラクティスを知っているなら、それをあなたの環境に穏やかに導入する最良の方法は、もちろん自分でそれを始めて、途中でどこかで、あなたの同僚の何人かが利益を見るでしょうそれを拾います。

ここでのキーワードは、革命ではなく進化です。