単体テスト初心者チームは単体テストが必要

私は歴史的にユニットテストを行っていない新しいチームで働いています。私の目標は、チームが最終的に TDD（テスト駆動開発）を自然なプロセスとして採用することです。しかし、TDDはユニットテスト以外のチームにとっては非常に急進的であるため、コーディング後にユニットテストを書くことから始めようと思いました。

誰も同じような状況にありましたか？チームがユニットテストを行っていないときにTDDに慣れるのに効果的な方法は何ですか？いくつかの手順でこれを行うのは理にかなっていますか？それとも、すぐに飛び込み、成長するすべての痛みに一度に直面する必要がありますか？

編集

明確にするために、チームには（私以外に）単体テストの暴露/経験を持つ人はいません。また、Visual Studioに組み込まれている単体テスト機能の使用を計画しています。

既存のバグ/欠陥の練習。

これは本当に厳しい状況です。私は以前からTDDに行ったことは一度もありませんでしたが、私の経験では、チームをユニットテストなしからプロアクティブに記述することは非常に「一度に1ステップ」のアプローチでした。

まず、ユニットテストを作成し、それらが何であるか、そしてそれらの利点を本当に理解するようにします。私のチームにとっては、既存のバグの単体テストを書くことが最善でした。システムの現在のバグには、ユニットテストを適切に作成することを人々に教えるために必要なものが2つあります。

1. 予想される前提条件と事後条件
2. 現在期待されているものではなく、その前提条件/事後条件に違反する結果

これは、メンバーに非常に具体的な実践例を与えます。バグを修正する前にテストを作成して、失敗するようにすることができます。その後、彼らはコードを修正して、それが成功するようにし、バグを修正することができます。彼らがこれに慣れたら、残りの部分を手に入れて、コードを事前に作成せずに単体テストを作成し、新しいコードを作成してテストに合格させることができます。

秘theは、明確な方法の事前/事後条件がある場所で、彼らに練習する何かを与えることだと思います。メソッドの要件があいまいな場合、経験豊富なTDDの人でさえ、どこから始めればよいかを正確に知ることは困難です。時間をかけて一歩進んでください。がんばろう！

私は会社全体にTDDに切り替えるよう説得しました。それは簡単ではありませんでしたが、努力の価値は十分にありました。移行後にコードの品質が上がり、今では恐ろしいカウボーイのコーディング時代に戻ることを誰も想像していません。

1. 説明、説明、説明。チームにテストを書いてほしくありません。チームにテストを作成してもらいたい。これは、なぜ彼らがそれを行うべきなのか、どのような利点があるのか​​、そしてこれが彼らの仕事をより簡単にする方法を完全に理解する必要があることを意味します。赤、緑、リファクタリング、バグが修正されたことを証明する回帰テストなど

2. 本物に進みます（最初のテスト、次にコード）。コードの後に​​テストを書くことはほとんど意味がありません。実際に動作するかどうかはわかりません（そして、バグのあるテストケースを書く人もいます）。私の直感は、あなたがから行く必要な努力の量ということでノーテストに最初のテストははるかに少ないあなたが形成されない行くために必要なものよりも何のテストを通過最初のコードに最初のテストあなたが同様に中央のステップをスキップするので、。

3. 回帰テストから始めます。これらは理解するのが非常に簡単で、すぐに満足できます。もちろん、これは、コードが適切にモジュール化され、簡単にテストできることを前提としています。そうでない場合は、この手順をスキップします。

4. 赤ちゃんの手順を実行します。TDDは慣れるまで時間がかかり、最初はイライラするかもしれません。まったく新しいプロジェクトまたはコンポーネントにテストを導入してください。理想的には、それほど重要ではないものです。本当に迅速に行うべき非常に重要なことがあり、プログラマーがTDDが邪魔になっていると感じている場合は、どうしても状況を回避したいです。

5. チームが快適になり始めたら、すべての新しい機能をTDD形式で作成します。これはプロジェクトのサイズに依存しますが、しばらくすると、プロジェクトの一部の古い部分のみが古い方法で記述された状態で、かなり良いカバレッジが得られるはずです。

6. この時点までに、チームはTDDを既に理解し、受け入れている必要があります。レガシー（非TDD）のものは困難で、扱いが面倒です。リファクタリングしてください：ほとんどのポプルは喜んでそれをします。

その他の重要なポイント：

• 使用可能な最高のテストフレームワークを使用していることを確認してください。不十分に書かれたライブラリと対話する必要がある場合、TDDを実行するように人々を説得するのははるかに困難です。

• テストが簡単に実行でき、完了までに時間がかからないようにします（または、たとえば、テストにメモリ内データベースを使用してチートします）。

• 壊れたテストがすぐに見つかるように、いくつかの継続的統合ソフトウェアをセットアップします。

TDDに慣れる1つの方法は、最初に統合テストを作成することです。後でテストシームと実際の単体テストを導入します。

コーディング後に単体テストを記述する際の問題は、コードがテスト可能なように必ずしも適切に設計されているとは限らないことです。テストの継ぎ目を導入するために、リファクタリングまたは再設計が必要になる場合があります。しかし、どのような種類のテストカバレッジもない場合、どのように安全にリファクタリングまたは再設計できますか？

統合テストは、最初にそのカバレッジを提供できます。回帰または本番の問題が発生するたびに、コードでそれを修正し、そのコードをテストでカバーします。このようなテストによって十分なセーフティネットが提供されると、システムのより細かく分離されたコンポーネントやクラスの単体テストを導入できます。

TDDは実装が非常に難しく、すべての開発チームにとって常に最適な選択肢とは限りません。私の以前の仕事では、チームはTDDに重点を置いていました。開発モデルは、アジャイル開発アプローチを使用した完全にTDDであり、テストはVisual Studioの単体テストを通じて行われました。

開発者が自分の機能の単体テストを作成しなかった場合、テクニカルリードに問題が生じます。さらに、誰かが壊れたビルドまたはユニットテストをチェックインした場合、開発者はすべての問題を修正し、チームマネージャーに1ドルを追加する必要があります。

追加するほんの小さなことは、プロセスを視覚化することです。継続的な統合でテストを自動的に実行し、コードカバレッジを確認します。誰でも見ることができるいくつかのスタートページに、最も完全なテスト済みモジュールをリストしてください。これにより、チームの競争が進むはずです。

私はJUnitの経験がまったくない状態からTDDに直接移行しましたが、その経験からTDDの価値が間違いなく明らかになりました。ユニットテストにとても感謝しているので、すぐにアプローチの伝道者になりました

私は単体テストを行わなかったチームに所属していましたが、導入され、現在いくつかのテストを行うことがほぼ一般的になっています。あなたのチームが単体テストの基本をどの程度理解しているか、またここにどんなツールを持ち込みたいかを探ることをお勧めしますか？

私の場合、ビジネスロジック、ユーザーインターフェイス、バックエンド機能が混在した.NetコードのnUnitを導入していました。チームの数人がそれを手に入れ、全員を取得しようとするフリップサイドよりも少し良く広がるように、他の人よりもそれを手に入れたいと思っている人がいるかどうかを見ることをお勧めしますこれに飛び込むために。最初にうまくやれるようにすることで、クロストレーニングが可能になり、それを拾った人が他の人にどれだけうまく教えることができるかをテストできます。

もう1つのポイントは、より多くの専門知識を持っている人を連れて、これをある程度見せるために検討することです。Thoughtworksは私が仕事をする場所に持ち込まれ、その一部は広く採用され、他の部分はそれほど普及していませんが、ほとんどの場所でそうだと思います。