unit-testing - 単体テストの開始

Question

単体テストとは、大まかに言えば、テスト コードを使用してコードの一部を分離してテストすることです。すぐに思いつく利点は次のとおりです。

• テストの実行が自動化および反復可能になる
• GUI を介したポイント アンド クリック テストよりもはるかに詳細なレベルでテストできます。

リトミス

私の質問は、ツールに関する現在の「ベスト プラクティス」とは何か、および日常のコーディングの一部としてユニット テストをいつ、どこで使用するかということです。

言語にとらわれず、すべてのベースをカバーするようにしましょう。

Answer 1

さて、単体テストを十分に行っていない人からのベストプラクティスをいくつか紹介します...咳。

1. テストが1 つ のことだけをテストしていることを確認してください。
2. 単体テストを作成します。できれば、テスト対象のコードを書く前に。
3. GUI の単体テストを行わないでください。
4. 懸念事項を分けてください。
5. テストの依存関係を最小限に抑えます。
6. モックを使用したモック動作。

Answer 2

TDD on Three Index CardsとThree Index Cards を参照して、テスト駆動開発の本質を簡単に思い出すことをお勧めします。

カード＃1。ボブおじさんの三原則

• 失敗したテストに合格する場合を除いて、製品コードを記述しないでください。
• 失敗を実証するのに十分なだけのテストを作成します。
• テストに合格するのに十分な量の製品コードのみを記述してください。

カード #2: 最初の原則

• 高速: 1 秒あたり数百または数千のように、気が遠くなるほど高速です。
• 分離: テストは障害を明確に分離します。
• 反復可能: 繰り返し実行でき、毎回同じように成功または失敗します。
• 自己検証: テストは明確に合否判定されます。
• タイムリー: コードを少し変更するだけで、ロックステップで作成されます。

カード #3: TDD のコア

• 赤: テストに失敗しました
• 緑: テストに合格
• リファクタリング: クリーンなコードとテスト

Answer 3

いわゆるxUnitフレームワークが広く使用されています。もともと Smalltalk 用に SUnit として開発され、Java 用の JUnit に進化し、現在では .Net 用の NUnit など、他の多くの実装が含まれています。これはほとんどデファクト スタンダードです。ユニット テストを使用していると言えば、他の開発者の大半は、xUnit などを意味していると想定します。

Answer 4

「ベスト プラクティス」の優れたリソースはGoogle Testing Blogです。たとえば、Writing Testable Codeに関する最近の投稿は素晴らしいリソースです。具体的には、「トイレでのテスト」シリーズの毎週の投稿は、キューブやトイレの周りに投稿するのに最適であるため、いつでもテストについて考えることができます.

Answer 5

xUnit ファミリーは、単体テストの主力です。それらは、Netbeans、Eclipse、および他の多くの IDE などに統合されています。これらは、単体テストに対するシンプルで構造化されたソリューションを提供します。

テストを書くときに私が常に心がけていることの 1 つは、外部コードの使用を最小限に抑えることです。つまり、テストのセットアップとティアダウンのコードを可能な限り最小限に抑え、他のモジュール/コード ブロックをできるだけ使用しないようにしています。適切に記述されたモジュラー コードは、そのセットアップとティアダウンにあまり多くの外部コードを必要とすべきではありません。

Answer 6

NUnitは、どの.NET言語にも適したツールです。

単体テストは、さまざまな方法で使用できます。

1. テストロジック
2. コードユニットの分離を増やします。関数またはコードのセクションを完全にテストできない場合は、それを構成する部分の相互依存性が高すぎます。
3. 開発を推進し、テストするコードを書く前にテストを書く人もいます。これにより、コードに何をさせたいかを考える必要があり、それを達成したときの明確なガイドラインが得られます。

Answer 7

リファクタリングのサポートを忘れないでください。.NET上のReSharperは、欠落しているコードの自動リファクタリングと迅速な修正を提供します。つまり、存在しないものへの呼び出しを作成すると、ReSharperは欠落している部分を作成するかどうかを尋ねます。