ALM 開発者の 1 日: ユーザーストーリーの新しいコードを作成する

[アーティクル]
02/21/2013

、Visual Studio のアプリケーションライフサイクル管理 (ALM) の新しいユーザーと Team Foundation Server (TFS) ですか。独自のアプリケーションをビルドするためには、チームの最新バージョンから最大の利点をこれらのツールを取得できるか迷うにはいるか。

その後、数分ウォークにこのチュートリアルで 2 " の手順に従ってかかり、Peter とジュリアの有線テレビおよび関連するサービスを提供するファイバー Fabrikam の架空の企業の 2 人の開発者の有効期間の日に従います。中断し、コードレビュー、チェックインを、変更要求、およびは他のタスクが表示されます場合は、コードをチェックアウトし、更新する方法の Visual Studio および TFS を使用するものが作業を中断します。

ここまでのストーリー

チームが最近アプリケーションライフサイクル管理 (ALM) の Visual Studio と Team Foundation Server の使用で。これらはバックログ作成され、イテレーション計画、およびそのほかの完了後、サーバーとクライアントコンピューターを各自のアプリケーションを開発するために必要な計画設定します。

この章の概要

Peter は簡単に自分のバックログを確認し、Mallory が今日するタスクを選択します。Bob は Alice に開発することを計画するコードの単体テストを作成します。通常、Mallory は数回テストを徐々により詳細なテストを記述し、それらに合格するコードを記述 1 時間の実行します。Mallory は、Alice に記述されたメソッドを使用するコンピューターに自分のコードのインターフェイスについて説明します。

[!メモ]

このトピックで説明する自分の作業とコードカバレッジ機能は Visual Studio Premium と Visual Studio Ultimateでのみ使用できます。

このトピックの内容

個人バックログを確認し、作業を開始するタスクを準備します。
最初の単体テストを作成します。
新しいコードのスタブを作成します。
最初のテストを実行します。
API に一致します。
赤、緑、リファクタリング…
コードカバレッジ
これは、されているか。
変更をチェックイン

個人バックログを確認し、作業を開始するタスクを準備します。

**[チームエクスプローラー]**では、Peter は [担当作業] ページが開きます。チームは、現在のスプリント中に、Evaluate Peter が請求書の状態に作業を、製品バックログの最も重要な項目同意しました。Peter は、実装の数値演算関数、最も重要なバックログ項目の子タスクから開始することになります。Mallory は 進行中の作業項目と変更 の一覧に [使用できる作業項目] の一覧からこのタスクをドラッグします。

個人バックログを確認し、作業を開始するタスクを準備するには

チームナビゲーターの担当作業ページの To Do リスト

チームエクスプローラーで、次の作業を行います。
1. 作業するチームプロジェクトにまだ接続されていない場合は、チームプロジェクトに接続します。
2. [ホーム]を選択し、**[担当作業]**を選択します。
[担当作業] のページで、[使用できる作業項目] の一覧から 進行中の作業項目 のセクションにタスクをドラッグします。

また [使用できる作業項目] の一覧のタスクを選択し、**[開始]**を選択できます。

下書きインクリメント作業の計画

Peter は、通常、一連の小さなステップのコードを開発します。各手順は 1 時間よりも、通常は受け取らず、10 分同様に負荷がかかることがあります。各ステップで、Mallory は新しいテストに合格した新しい単体テストを記述して、Bob が Mallory が既に作成されているテストに追加開発中のコードを変更します。Mallory は、コードを変更する前に、新しいテストを記述して、テストを記述する前にコードを変更します。場合によっては、リファクタリング。つまり、Mallory は新しいテストを追加せずにコードのみが向上します。Mallory は、正しく条件を表さなかったことを、Bob が決定する、成功しているテストは変更されません。

すべての小さなステップの末尾に、そのコードのこの領域に関連するすべての単体テストを実行します。Mallory は、すべてのテストに合格するまで手順を完了しませんでした。

ただし、Mallory は Team Foundation Server に、全体がタスクを完了するまでコードをチェックしません。

Peter は、この小さなステップのシーケンスの大まかな計画を書き込みます。Bob は Alice が動作するように新しい物の正確な詳細、および順序を変更することを認識します。この特定のタスクについて、手順の自分の最初の一覧を次に示します。:

スタブあることをテストメソッドは、メソッドの定義を作成します。
1 種類の一般的なケースを満たすします。
広いスコープをテストします。コードが値の大きい範囲に正しく応答することを確認します。
負の例外。適切にへと不正なパラメーター。
コードカバレッジ。コードの少なくとも 80% は、単体テストで実行することを確認します。

自分のユーザーの一部この種類のテストコードのコメントの計画を書き込みます。他のユーザーが計画を暗記します。Peter は、タスクの作業項目の説明フィールドの手順の自分のリストを記述すると便利なことがあります。Mallory がそれに戻れるときに、一覧の場所を、Bob が Mallory わかっている場合は、緊急のタスクに変換する必要があります。

最初の単体テストを作成します。

Peter は、単体テストを作成します。Mallory は単体テストから Bob が Mallory の新しいクラスを使用するコードの例を記述するため、開始します。

これにより、Mallory がテストしているため、Mallory は新しい単体テストプロジェクトを作成します。クラスライブラリの最初の単体テストです。次に、は [新しいプロジェクト] のダイアログボックスを開き、Visual C#、**[テスト]**と **[単体テストプロジェクト]**を選択します。

[新しいプロジェクト] ダイアログで選択された単体テスト

単体テストプロジェクトは、Bob が Mallory の例を作成できます。C# ファイルを提供します。この段階では、Mallory は、自分の新しいメソッドの 1 つが呼び出される方法についてする場合:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Fabrikam.Math.UnitTest
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        // Demonstrates how to call the method.
        public void SignatureTest()
        {
            // Create an instance:
            var math = new Fabrikam.Math.LocalMath();

            // Get a value to calculate:
            double input = 0.0;

            // Call the method:
            double actualResult = math.SquareRoot(input);

            // Use the result:
            Assert.AreEqual(0.0, actualResult);
        }
    }
}

Mallory は、自分のコードを記述することで、Mallory が、例に動作するため、テストメソッドの例を書き込みます。

単体テストプロジェクトとメソッドを作成します。

通常、テスト対象のプロジェクトごとに新しいテストプロジェクトを作成します。テストプロジェクトが既に存在する場合は、新しいテストクラスとメソッドを追加できます。

この手順では、Visual Studio の単体テストフレームワークを使用して、他のプロバイダーからフレームワークを使用できます。テストのエクスプローラー、他のフレームワークを適切なアダプターをインストールし、同様に使用します。

まだない場合は、テストプロジェクトを作成します。
- [新しいプロジェクト] のダイアログボックスで、[Visual Basic]、[Visual C++] または **Visual C#**などの言語を選択します。次に [テスト] と **[単体テストプロジェクト]**を選択します。
用意されているテストクラスにテストを追加します。各単体テストには、1 とおりの方法があります。

各単体テストには、TestMethod の属性で始まるあることが必要で、単体テストメソッドは、パラメーターを持たない必要があります。は、単体テストメソッドに使用する名前を使用できます:
```
        [TestMethod]
        public void SignatureTest()
        {...}
```
```
    <TestMethod()>
    Public Sub SignatureTest()
    ...
    End Sub
```
各テストメソッドは、成功したか失敗したかを示すために Assert クラスのメソッドを呼び出す必要があります。通常は操作の予期された結果と実際の結果が等しいことを確認します:
```
Assert.AreEqual(expectedResult, actualResult);
```
```
Assert.AreEqual(expectedResult, actualResult)
```
テストメソッドは TestMethod の属性を持たない他の通常のメソッドを呼び出します。
複数のクラスにテストを編成できます。各クラスは TestClass の属性で始まる必要があります。
```
[TestClass]
public class UnitTest1
{ ... }
```
```
<TestClass()>
Public Class UnitTest1
...
End Class
```

C++ 単体テストを作成する方法の詳細に C++ 用の Microsoft 単体テストフレームワークを使用した C++ 用単体テストの記述を参照してください。

新しいコードのスタブを作成します。

次に、Peter は、自分の新しいコードのクラスライブラリプロジェクトを作成します。これで、コードのプロジェクトおよび単体テストに開発中のプロジェクトができます。Mallory は、開発中のテストプロジェクトからコードへのプロジェクト参照を追加します。

テストとクラスプロジェクトがあるソリューションエクスプローラー

新しいプロジェクトに、Mallory は少なくともテストが正常にビルドするためのメソッドの新しいクラスと最小のバージョンを追加します。テストするの呼び出しのクラスおよびメソッドのスタブを生成する最も簡単な方法です。

        public double SquareRoot(double p)
        {
            throw new NotImplementedException();
        }

テストのクラスおよびメソッドを生成します。

最初にまだない場合は、新しいクラスを追加するプロジェクトを作成します。

クラスを生成するには

するクラス、たとえば、を LocalMathの例にカーソルを生成し設定します。ショートカットメニューで、[コードの生成]、**[新しい型]**を選択します。
[新しい型] のダイアログボックスでは、クラスライブラリプロジェクトに [プロジェクト] を設定します。この例では、Fabrikam.Mathです。

メソッドを生成します。

たとえば、SquareRoot、メソッドの呼び出しにカーソルを置きます。ショートカットメニューで、[コードの生成]、**[メソッドスタブ]**を選択します。

最初のテストを実行します。

Peter のビルドと実行の T キーを押してテスト。テスト結果は赤のインジケーターと失敗したテストが **[失敗したテスト]**の一覧の下に表示されることを示します。

1 つのテストが失敗したことを示す単体テストエクスプローラー

Mallory はコードへの簡単な変更を加えます:

       public double SquareRoot(double p)
        {
            return 0.0;
        }

Mallory は、テストを再実行して、成功:

1 つのテストが成功したことを示す単体テストエクスプローラー

単体テストを実行するには

[すべて実行] ボタンを示すテストエクスプローラー

[テスト] で、メニューの [実行]、**[すべてのテスト]**を選択します。

または
テストのエクスプローラーが開いている場合は、**[すべて実行]**を選択します。

または
テストコードファイルと入力し **[CTRL+R, T]**にカーソルを置きます。
テストが **[失敗したテスト]**の下に表示する場合:

名前をダブルクリックして、たとえば、テストを開きます。

テストの失敗が表示される点。

テストの一覧を表示するには、 は [すべて表示]を選択します。概要に戻るには、[ホーム] ビューを選択します。

テスト結果の詳細を表示する、 は、テストのエクスプローラーでテストを選択します。

テストのコードに移動するには、 のダブルクリックには、テストのエクスプローラーのテスト、またはショートカットメニューの [テストを開く] を選択します。

が開きますテストをデバッグするには、 は、一つ以上のテストのショートカットメニューで、を **[選択したテストのデバッグ]**を選択します。

ソリューションをビルドするたびにバックグラウンドでテストを実行するには、 のトグル [ビルド後にテストを実行]。前にエラーが最初に実行されるテスト。

インターフェイスを一致します。

Peter は Lync の自分のコンピュータージュリアを呼び出し、自分の画面を共有します。Alice が Bob のコンポーネントを使用します。Bob は Alice の最初の例を示します。

ジュリアをテストします。この例では」、OK 「がコメントが、多くの関数を渡すと思い込みます

Peter は、応答「最初のテストは、関数の名前とパラメーターが正しいことを確認します。ここで、この関数の主要な要件」をキャプチャするテストを記述できます。

この二つの部分は次のテストを記述します:

  
      [TestMethod]
        public void QuickNonZero()
        {
            // Create an instance to test:
            LocalMath math = new LocalMath();

            // Create a test input and expected value:
            var expectedResult = 4.0;
            var inputValue = expectedResult * expectedResult;

            // Run the method:
            var actualResult = math.SquareRoot(inputValue);

            // Validate the result:
            var allowableError = expectedResult/1e6;
            Assert.AreEqual(expectedResult, actualResult, allowableError,
                "{0} is not within {1} of {2}", actualResult, allowableError, expectedResult);
        }

ヒント
この関数では、Peter は、が最初に機能の単体テストを作成および使用して、テストを満たすコードをテストファースト開発を書き込みます。また、Mallory は、コードを記述したら、この方法がその代わりに、現実的、そのテストを記述しないことがわかります。ただし、は、コードを一定に保つため、コードの単位を記述することは非常に重要かどうかをテストする前または後に検討します。

この関数では、Peter は、が最初に機能の単体テストを作成および使用して、テストを満たすコードをテストファースト開発を書き込みます。また、Mallory は、コードを記述したら、この方法がその代わりに、現実的、そのテストを記述しないことがわかります。ただし、は、コードを一定に保つため、コードの単位を記述することは非常に重要かどうかをテストする前または後に検討します。

赤、緑、リファクタリング…

Peter は、Bob が繰り返し場合は、コードをテストに渡させる、リファクタリングを考慮するテストを作成すると検証サイクルに続行され、コードをテストを変更せずに向上します。

赤

Peter は、Bob がジュリアで作成した新しいテストを実行するために、T キーを押します。これがテストを作成したら、常に、実行、が合格するコードを記述する前に失敗することを確認します。これにより、Mallory は自分が作成したテストにあるアサーションを設定するのを忘れてしたら、Bob が学んだ方法です。エラーの結果を確認できると条件が満たされていることを自分で合格すると、テスト結果に適切な名前を作成できます。

もう一つの便利な方法は **[ビルド後にテストを実行]**を設定することです。このオプションは、コードのテストの状態を絶え間、レポートを持つようにソリューションをビルドするたびに背景のテストを実行します。Peter は、応答するため、低速な Visual Studio に対しては、はですが、最初に疑ったこれが頻繁に発生しないことがありました。

1 つのテストが失敗したことを示す単体テストエクスプローラー

緑

Peter は、自分が開発するメソッドのコードで、最初の操作を記述します:

    public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate;
                estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }

Peter は、テストを再実行して、すべてのテストに合格する:

2 つのテストが成功したことを示す単体テストエクスプローラー

リファクタリング

コードが main 関数を実行すると、Peter は、を行う方法をより適切に実行検索するか、それを将来変更しやすくするコードが表示されます。Mallory は、ループで実行する計算の数を減らしてであることが判明します:

public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate; 
                estimate = (estimate + x / estimate) / 2;
                //was: estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }

Mallory はテストがまだ渡すことを確認します:

2 つのテストが成功したことを示す単体テストエクスプローラー

ヒント
コードをリファクタリングや拡張する必要がある開発中に行われた変更: リファクタリングに新機能が追加されないため、テストを変更しないことを意味します。拡張子はテストの追加、既存、新しいテストに合格する必要のあるコード変更の行のを意味します。変更した要件に既存のコードを更新する場合や、現在の条件を表さない古いテストを削除します。既に越えているテストを変更しないようにします。代わりに、新しいテストを追加します。実際の条件を表すテストのみを記述します。すべての変更後のテストを実行します。

コードをリファクタリングや拡張する必要がある開発中に行われた変更:

リファクタリングに新機能が追加されないため、テストを変更しないことを意味します。
拡張子はテストの追加、既存、新しいテストに合格する必要のあるコード変更の行のを意味します。

変更した要件に既存のコードを更新する場合や、現在の条件を表さない古いテストを削除します。

既に越えているテストを変更しないようにします。代わりに、新しいテストを追加します。実際の条件を表すテストのみを記述します。

すべての変更後のテストを実行します。

… Then 繰り返し

Peter は大ざっぱなガイドラインとして小さなステップの自分の一覧を使用して、自分の一連の拡張機能とリファクタリングの手順を続行します。Mallory は、拡張子の後にリファクタリングの手順を常に実行せずに、複数のリファクタリングの手順を続けて実行します。ただし、Mallory はコードへの変更の後に単体テストを常に実行されます。

Mallory は、自分のコードが正しく動作するようにコードを変更する必要はありませんが、自分の作成に追加テストを追加します。たとえば、Mallory は関数が入力が動作することを確認します。Mallory は、この 1 などの追加のテストを作成します:

        [TestMethod]
        public void SqRtValueRange()
        {
            LocalMath math = new LocalMath();
            for (double expectedResult = 1e-8;
                expectedResult < 1e+8;
                expectedResult = expectedResult * 3.2)
            {
                VerifyOneRootValue(math, expectedResult);
            }
        }
        private void VerifyOneRootValue(LocalMath math, double expectedResult)
        {
            double input = expectedResult * expectedResult;
            double actualResult = math.SquareRoot(input);
            Assert.AreEqual(expectedResult, actualResult, expectedResult / 1e6);
        }

このテストは最初に実行されます:渡します。

3 つのテストが成功したことを示す単体テストエクスプローラー

この結果を確認することは、自分のテストに誤り、その一時的により、が失敗する小さなエラーではありません。失敗に会った後、Mallory は再度修正。

ヒント
これに合格する前にテストを常に失敗します。

例外

Peter は、例外的な入力のテストを記述して、に移動します:

[TestMethod]
        public void RootTestNegativeInput()
        {
            LocalMath math = new LocalMath();
            try
            {
                math.SquareRoot(-10.0);
            }
            catch (ArgumentOutOfRangeException)
            {
                return;
            }
            catch
            {
                Assert.Fail("Wrong exception on negative input");
                return;
            }
            Assert.Fail("No exception on negative input");
        }

このテストはループにコードを入力します。Mallory はテストのエクスプローラーに [キャンセル] のボタンを使用する必要があります。これは、10 秒以内のコードを終了します。

Peter は、無限ループがビルドサーバーに行うことができないようにする場合。サーバーが完全な実装にタイムアウトを設定が、非常に長いタイムアウトに、多くの遅延が発生します。そのため、Mallory はこのテストに明示的なタイムアウトを追加します:

        [TestMethod, Timeout(1000)]
        public void RootTestNegativeInput()
        {...

明示的なタイムアウトはテストが失敗する。

Peter はこの例外的なケースを処理するためにコードを更新します:

       public double SquareRoot(double x)
        {
            if (x <= 0.0) 
            {
                throw new ArgumentOutOfRangeException();
            }

回帰

新しいテストに合格が、回帰があります。これで、渡すために使用したテストは失敗します:

以前は成功したが失敗した単体テスト

Peter の検索と修復誤り:

      public double SquareRoot(double x)
        {
            if (x < 0.0)  // not <=
            {
                throw new ArgumentOutOfRangeException();
            }

これを修正してから、すべてのテストに合格する:

4 つのテストが成功したことを示す単体テストエクスプローラー

ヒント
テストのパスをコードに行われた変更の後に続き確認します。

コードカバレッジ

自分の作業の間の間隔、そのコードがチェックイン、Peter コードカバレッジレポートを取得する前に、finally。これは、実行されたいるコードの量自分のテストに示します。

Peter のチームは、少なくとも 80% のカバレッジを向けます。これらのプロパティは、コードでこの型の高い柔軟性を実現するのは困難な場合があるため、生成されたコードに対してこの要件を緩和します。

優れた柔軟性はコードの入力値のすべてのスコープの動作コンポーネントのすべての機能がテストされた、という保証されるわけではありません。いずれにしても、コード行の適用範囲とコンポーネントの動作の空間の適用範囲内に非常に近い相関関係があります。したがって、優れた柔軟性は、に含まれているほとんどの動作をテストしているチームのほとんどを強化します。

コードカバレッジレポートは、[テスト] のメニューで取得するには、[実行]、**[すべてのテストのコードカバレッジの分析]**を選択します。次に、すべてのテストを再実行します。

コードカバレッジの結果と色の設定ボタン

Peter は合計 86% の適用範囲を取得します。Mallory がレポートの合計を配置するときに、自分が開発中のコードに 100% の柔軟性があることを示します。これは重要な点がテスト中にコード用であるため、非常にコンテンツです。見つかったを取得されたセクションには、テスト自体に実際にあります。[コードカバレッジの色分けを表示] のボタンを使用して、Peter は、テストコードのどの部分が実行されなかったかを確認できます。ただし、Mallory はエラーが検出されている場合にのみ、テストコードで、使用するため、これらのセクションが適用範囲にとって重要でないと判断します。

特定のテストがコードの特定の分岐に達することを確認するには、[コードカバレッジの色分けを表示] を設定し、ショートカットメニューの [実行] のコマンドを使用して、一つのテストを実行できます。

これは、されているか。

Peter は、自分が終了するまで小さなステップのコードを更新します:

使用可能なすべての単体テストに合格します。

非常に多くの単体テストでのプロジェクトでは、実行するようにすべてを待機することは、開発者が適切でない場合があります。代わりに、プロジェクトがソースツリーにマージする前に、すべての自動テストがそれぞれのチェックインされたシェルブセットに対して動作するゲートチェックインのサービスを操作します。チェックインは、実行が失敗した場合は拒否されます。これにより、他の作業を発生させることなく開発者が自分のコンピューター上に構築、続行され、最小限の単体テストを実行することによってビルドが中断されます。詳細については、「変更内容を検証するためのゲートチェックインビルドプロセスの定義」を参照してください。
コードカバレッジはチームの標準にします。75% では、一般的なプロジェクトの要件です。
自分の単体テストが要求される一般的に、例外的な入力を伴う動作の要素をシミュレートします。
自分のコードは、理解、拡張しやすくなります。

これらの条件がすべて満たされたときに、Peter は、ソース管理、自分のコードをチェックする準備が整いました。

単体テストを使用してコード開発の原則

Peter は、開発コードと次の原則が適用されます:

単体テストをコードとともに開発し、開発中に頻繁に実行します。単体テストは、コンポーネントの仕様を表します。
要求が変更されない場合、またはテストが誤っている場合は、変更単体テストは。コードの機能を拡張すると、新しいテストを徐々に追加します。
テストでカバーされたコードの少なくとも 75% では目指します。ソース・コードをチェックインする前に間隔をコードカバレッジ結果を、" " を参照してください。
連続または標準ビルドサーバーで実行するように、コードと組み合わせて、単体テストをチェックインします。
機能、の各部分のは実用的には、単体テストを作成します。これを満たすコードを開発する前にで設定します。

変更をチェックイン

自分の変更をチェックインする前に、Peter は再び自分のコンピュータージュリアと Bob の画面を共有するに Lync を使用して、自分が作成した内容が、非公式および相互に自分で確認できます。テストはない機能や動作コードの処理にジュリアが主に関心があるため、ディスカッションのフォーカスとして機能します。ジュリアは、同意する必要が表示されるように、Peter 記述したか。

Peter のチェックインは、管理者が完了したタスクと自分が行ったすべての変更は、テストとコードの両方が、それらを関連付けます。チェックインが CI チームのビルドのビルドプロセスを使用して、自分の変更を検証するためにチームの自動化されたチームビルドシステムをキューに配置します。このビルドプロセスは、チームがビルドによってコードベースのエラーを最小化し、開発とは別の問題のない環境でテストコンピューター変更はすべて、チームなります。

Peter は、ビルドが完了したときに通知されます。ビルド結果ウィンドウで、Mallory はビルドが成功して、すべてのテストに合格したことがわかります。

変更をチェックイン

保留中の変更のチェックイン

メニューバーの [表示]、[チームエクスプローラー] を選択します。
[チームエクスプローラー]では、[ホーム] を選択し、**[担当作業]**を選択します。
[担当作業] のページで、**[チェックイン]**を選択します。
ように [保留中の変更] ページの内容を確認します:
- **[含まれる変更]**のすべての関連する変更が一覧表示
- 関連するすべての作業項目は **[関連作業項目]**に示します。
それらが変更されたファイルとフォルダーのバージョン管理履歴を表示するとき、チームがこれらの変更の目的を理解できるように [コメント] を指定します。
[チェックイン] を選択します。

常にコードを統合するには

継続的な統合ビルド処理を定義する方法の詳細については、継続的インテグレーションをサポートするようにビルドプロセスを定義するを参照してください。このビルドプロセスを設定した後、チームビルド結果に関する通知を受け取るように選択できます。

CI ビルドに成功したことが Peter に通知されます

CI ビルドの結果

詳細については、「ビルドの実行、監視、管理」を参照してください。

次に、(作業を中断し、バグを修正し、コードレビューを行います。)

ALM 開発者の 1 日: ユーザー ストーリーの新しいコードを作成する

個人バックログを確認し、作業を開始するタスクを準備します。

個人バックログを確認し、作業を開始するタスクを準備するには

下書きインクリメント作業の計画

最初の単体テストを作成します。

単体テスト プロジェクトとメソッドを作成します。

新しいコードのスタブを作成します。

テストのクラスおよびメソッドを生成します。

クラスを生成するには

メソッドを生成します。

最初のテストを実行します。

単体テストを実行するには

インターフェイスを一致します。

赤、緑、リファクタリング…

赤

緑

リファクタリング

… Then 繰り返し

例外

回帰

コード カバレッジ

これは、されているか。

単体テストを使用してコード開発の原則

変更をチェックイン

変更をチェックイン

常にコードを統合するには

その他のリソース

ALM 開発者の 1 日: ユーザーストーリーの新しいコードを作成する

単体テストプロジェクトとメソッドを作成します。

コードカバレッジ