単体テストの価値を説明する方法
単体テスト（およびテスト全般）の概念を同僚に紹介したいと思います。現在、テストはまったく行われていません。UIを介して実際にタスクを実行し、目的の結果を確認することでテストを行っています。ご想像のとおり、コードは正確な実装と非常に緊密に結合されています。クラス全体に存在し、システム全体で再利用されるべきコードがメソッド間でコピーおよび貼り付けされることになります。
変更された要件のため、以前に作成したモジュールを変更するように求められましたが、それはかなり疎結合です（希望するほどではありませんが、他の多くの概念を導入する必要なく、できる限り得ることができます）。予想どおりに機能することを「証明」し、テストがどのように機能するかを示すために、改訂したコードに一連の単体テストを含めることにしました。一部のコードは既に記述されているため、本当のTDDに従っていませんが、作成する必要がある新しいコードについては、いくつかのTDDの概念に従うことを望んでいます。
さて、必然的に私がコードを書くのに1日か2日以上かかるのはなぜかと問われるでしょう。私がやり取りするものの一部はシステムに既に存在しているためです（テストなしで非常にしっかりと）結合）、そしてコードをチェックインすると、この「テスト」プロジェクトが何であるかを尋ねられます。テストの基本を説明することはできますが、他の人が理解する方法で実際の利点を説明することはできません（テストではアプリを自分で実行する必要があると考えているためです。 " か否か）。彼らは疎結合の概念を理解していません（疎結合が何もないという事実から明らかです;私が書いたコードの外部にインターフェースさえもない）ので、それを利益として使用することはおそらく私に利益をもたらすでしょう「えっ？」見た目も同じですし、既存のモジュールをいくつか作り直したり、「プログラミング」ではなく時間の浪費と見なしたりするIoCコンテナを導入したりする必要がないので、私が望むほどルーズになることはできません。
私がこのコードを指し、「ユニットテストの作成を開始する必要がある」と言っても、どちらかと言えば妥協する必要はありません（たとえば、「テストを書くと、良いコードを書くように強制されます」）。私のもの以外はbad）であるか、それとも実際の価値を追加しない時間の無駄のように見えることなく？
単体テスト（および一般的なテスト）の概念を同僚に紹介したい
概念的な側面からではなく、実用的な側面から始める方が良いと思います。もちろん、カジュアルなディスカッション中に、同僚や管理者がユニットテストについて聞くことに興味を持っていることがわかった場合は、さらに良いでしょう。具体的な経験やWebからの証拠をグーグルで調べたり、簡単なトレーニングをまとめたりすることができます。しかし、あなたの説明から、チームメイトはこの奇妙な新しいアイデアに対してあまりオープンではないようです。
そのような状況では、私は最初に誰かにあまり多くを説明しようとせずに私の小さな単体テストを書き始めるだけです。すべてのコードを徹底的にカバーしようとせずに、コードを変更するたびにそれらのいくつかを追加します（非常に長い時間がかかります）。理想的には、うまくバランスをとることができれば、ユニットテストを書いていることに気付くまでに、かなりのテストスイートといくつかの具体的な結果が表示されている可能性があります（「このテストケースで、バグをキャッチできた先週の変更で導入されました。変更しないとQA /本番環境に移行します」）。これは、真剣な開発者にとってテストの価値を証明します。
その後、私はユニットテストの長期的な利点を説明するための良い立場にいます
- それはコードが機能することを証明します-いつでも、どこでも、瞬時にそして自動的に
- リファクタリングの信頼性を高め、設計の改善と保守性の向上をもたらします。
- 何かが壊れた場合は、バグが別のQA部門によって発見された場合の数日または数週間のレイテンシとは対照的に、ユニットテストは（ほぼ）即時のフィードバックを提供します。これにより、通常、短時間のメモリから削除されて以来、数時間または数日間デバッグするのではなく、数秒でバグを修正できます。
この関連スレッドもご覧ください： 自動化された単体テスト、統合テスト、受け入れテスト 。
そしてSOからの以前のもの： 単体テストとは何ですか？
恐怖のないリファクタリング
少し異なる角度として、TDDは「恐れることなくリファクタリング」することを可能にします。これは、チームを販売できる主な利点です。開発者が自分に言い聞かせないようにします。
- 「改ざんするのではないかと思うので、このコードには触れたくない」
- 「このコードの仕組みを知らないので、このコードに新しい機能を書きたくありません。」
- 「ひそかに、私はそのコードを恐れている」
私はより多くのことをハープすることができましたが、これは TDDのボブおじさん や TDDのマーティンファウラー などの十分にカバーされたグラウンドです。
依存関係
あ、もう一つ追加します。 TDDが優れた設計を強制する方法を示し、依存関係を適切に処理できるようにします。
ボブ：「ああc％^ p！上司は私たち全員にMS SQL Server 2008の使用を強制しただけです」ジェーン：「それは問題ありません。データソースとDAOクラスをDIしたので、被害は最小限に抑えられました。TDDが奨励してとても嬉しいです私たちはその道を進みます。」
計算する
- tmt =考えられる影響があると思われるすべてのものを手動でテストするのに必要な時間
- twt =テストの作成に必要な時間
k =新しいコードをリリースする前にすべてをテストする必要がある回数
もし（twt <tmt）または（twt <（k * tmt））そして、それは非常に簡単です：テストを書くことは開発を加速します。
そうでない場合は、比率（twt /（k * tmt））。数が非常に多い場合は、別の機会を待ちます。それ以外の場合は、回帰テストのメリットを正当化します。
注：私はこの時点でユニットではなく機能のみをテストすることをお勧めします-正当化して理解するのがはるかに簡単で、間違いなくユニットよりも高い値で作業が少ないリファクタリング時のテスト。
注2：テストは自動化されているため、テストを実行するのに時間がかかります問題ではありません。テストの実行中に他の生産的なことを行うことができますを除いて、テストの実行には時間がかかりすぎて、締め切りに間に合わなくなります。それはまれです。
自動テストのないソースコードで作業している間は、細心の注意を払って作業する必要があり、既存の機能を損なうことのないような変更を確実に行うには、さらにレビューが必要です。
適切な自動テストケースがある場合、結果はより速く、自信があり、恐れを知らない開発になります（バグの修正、拡張、またはリファクタリングになる可能性があります）。
あなたがマイクロソフトショップである場合の1つの提案：ベストプラクティスとしてユニットテストまたは疎結合を推奨するMSDNのドキュメントをいくつか検索し（ this のインスタンスが複数あると確信しています）、ある場合はそれを指摘します対立。
物事をするのはひどい方法のように聞こえるかもしれませんが、「ベストプラクティス」という用語を使用すると、特に管理に関して長い道のりがかかることがわかりました。
私がいつもお勧めしているように、あなたが素晴らしい習慣を知っているなら、それをあなたの環境にそっと導入する最良の方法はもちろんそれを自分で始めて、そして途中のどこかで、あなたの同僚の何人かが利点を見て、それを拾います。
ここでのキーワードは革命ではなく進化です。