xUnitを使用してASPを記述する.NET Coreユニットテスト

15605 ワード

覚えてるNET FrameworkのASP.NET WebFormですか?あの年代、Web層でユニットテストをするのは災難だっただろう.NET Coreは教訓を学び、設計上テスト性を考慮し、ASP.NET CoreというWebやAPIアプリケーションはユニットテストをするのも便利です.その中でインタフェース向けと依存注入はこの点で非常に重要な役割を果たした.
ここでは、xUnit対ASPの使い方を手で教えてあげます.NET Coreアプリケーションはユニットテストを行います..NET Coreでよく使われるテストツールにはNUnitとMSTestがありますが、私自身はxUnitをテストツールとして使うことに慣れているので、本稿ではxUnitを使用します.

サンプルアイテムの作成

まずASPを使う.NET Core APIテンプレートはアプリケーションを構築します.
テンプレートはValuesControllerを自動的に作成し、プレゼンテーションを容易にするためにGetメソッドの1つだけを残します.

public class ValuesController : ControllerBase
{
// GET api/values/5
    [HttpGet("{id}")]
public ActionResult<string> Get(int id)
{
return "value";
    }
}

次に、xUnitユニットのテスト項目を追加します.
テンプレートは、xUnitリファレンスを自動的に追加します.

<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.9.0" />
<PackageReference Include="xunit" Version="2.4.0" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.4.0" />
ItemGroup>

ただしASPをテストする.NET Coreアプリケーションでは、2つのNuGetパッケージを追加する必要があります.

Install-Package Microsoft.AspNetCore.App
Install-Package Microsoft.AspNetCore.TestHost

もちろんターゲットプロジェクトも導入します.最後の参照は次のとおりです.

<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.5" />
<PackageReference Include="Microsoft.AspNetCore.TestHost" Version="2.1.1" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.9.0" />
<PackageReference Include="xunit" Version="2.4.0" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.4.0" />
ItemGroup>

<ItemGroup>
<ProjectReference Include="..\WebApplication1\WebApplication1.csproj" />
ItemGroup>

リファレンスを追加してコンパイルし、リファレンスに問題がないことを確認します.

ユニットテストの作成

書き込みユニットテストには、通常、Arrange、Act、Assertの3つのステップがあります.
Arrangeは準備段階であり、この段階はシミュレーションデータ、初期化オブジェクトなどの準備作業である.
Actは動作段階であり、この段階は準備されたデータでテストする方法を呼び出す.
Assertは断定フェーズであり,呼び出しターゲットメソッドが返す値と予想される値を比較し,予想と一致してテストに合格しないと失敗する.
この手順に従って、ValuesControllerのGetメソッドをテストの目標とするユニットテスト方法を作成します.一般的なユニットテスト方法はテスト例です.
テストエンジニアリングでValuesTestsユニットテストクラスを追加し、次のようにユニットテスト方法を作成します.

public class ValuesTests
{
public ValuesTests()
{
var server = new TestServer(WebHost.CreateDefaultBuilder()
            .UseStartup());
        Client = server.CreateClient();
    }

public HttpClient Client { get; }

    [Fact]
public async Task GetById_ShouldBe_Ok()
{
// Arrange
var id = 1;

// Act
var response = await Client.GetAsync($"/api/values/{id}");

// Assert
        Assert.Equal(HttpStatusCode.OK, response.StatusCode);
    }
}

ここではTestServerを介してHttpClientオブジェクトを取得し、Httpリクエストをシミュレートすることができます.セルテストのArrange,Act,Assertの3つのステップを完全に実証する非常に簡単なテスト例を書いた.
推奨ユニットテストのメソッド名は、「何が何であるべきか」のモードを使用します.例えば上のGetById_ShouldBe_Okは、GetByIdというAPIを呼び出して返された結果がOKであるべきであることを示しており、このように見ると、あなたのこのテスト例が何をしているのかがわかり、あまり注釈を必要としません.

ユニットテストの実行

ユニットテスト用例を作成したら、「Test Explore」(中国語版VSで見たのは中国語)を開き、テスト方法で右クリックし、「Run Seleted Tests」を選択し、方法コードブロック内でマウスで右クリックして「Run Tests」を選択することもできます.
注意テスト方法の前のアイコンの色を見てください.現在は青で、テスト例がまだ実行されていないことを示しています.
テストケースの実行が終了すると、結果が予想通りに一致すると緑色のアイコンになります.
実行結果が予想と一致しない場合は赤いアイコンになり、緑のアイコンが表示されるまでコードを変更する必要があります.「Test Explore」の下には、実行にかかる時間が表示されます.また、「Output」ウィンドウで実行の詳細が表示されます.
以上のアイコンの色の変化過程は、青、赤、さらに緑で、青が1回の運転を経て直接緑になる可能性があり、何度も赤を経て緑になる可能性があります.テスト駆動開発におけるBRG(青赤緑)用語はこうである.

デバッグユニットテスト

ブレークポイントを追加することで、ユニットテストでデバッグできます.方法は簡単で、デバッグが必要な方法を右クリックして「Debug Seleted Tests」を選択すれば、通常のデバッグと同じです.
APIが具体的に何を返しているかを確認する場合は、ブレークポイントデバッグを追加して結果を返す変数文字列値を表示できますが、この方法は最善の選択ではありません.たとえば、同じAPIでは、10種類のパラメータが返す結果がどのようなものかを見てみましょう.毎回ブレークポイントデバッグで見るのは面倒です.
ブレークポイントを追加してデバッグするだけでなく、ログを印刷する方法もあります.xUnitは簡単にできます.そこでValuesTestsを修正します.

public ValuesTests(ITestOutputHelper outputHelper)
{
var server = new TestServer(WebHost.CreateDefaultBuilder()
        .UseStartup());
    Client = server.CreateClient();
    Output = outputHelper;
}

public ITestOutputHelper Output{ get; }

// ... (      )

ここでは構造関数にITestoputHelperパラメータを追加し,xUnitはこのインタフェースを実装するインスタンスを注入する.このインスタンスを入手すると、ログを出力できます.

[Fact]
public async Task GetById_ShouldBe_Ok()
{
// Arrange
var id = 1;

// Act
var response = await Client.GetAsync($"/api/values/{id}");

// Output
var responseText = await response.Content.ReadAsStringAsync();
    Output.WriteLine(responseText);

// Assert
    Assert.Equal(HttpStatusCode.OK, response.StatusCode);
}

実行(Debugではないことに注意)この方法は、実行終了後、「Test Explore」の下に「Output」と表示され、クリックすると出力の結果が表示されます.図のように:
このようにして、テストを実行するたびに、出力結果を簡単に表示することができます.

その他

上記では、HttpリクエストをシミュレートすることによってAPIテストを呼び出し、newのControllerがそのActionメソッドを直接呼び出すことによってテストしました.たとえば、

// Arrange
var id = 1;
var controller = new ValuesController();
// Act
var result = controller.Get(id);

Controllerが他に依存していない場合、この方法はもちろん最も便利です.しかし、通常、Controllerには1つ以上の依存があります.たとえば、次のようにします.

public class ValuesController : Controller
{
private readonly ISessionRepository _sessionRepository;

public ValuesController(ISessionRepository sessionRepository)
{
        _sessionRepository = sessionRepository;
    }

// ...
}

このControllerのすべての依存をインスタンス化するには、もちろん手動シミュレーションは現実的ではありません.1つの依存クラスが他のクラスやインタフェースに依存する可能性があり、依存チェーンが長い可能性があり、すべての依存が手動でインスタンス化することはできません.Moqというツールは、インスタンス化依存を自動的にシミュレートすることができます.その使い方は次のとおりです.

// ..
// Arrange
var mockRepo = new Mock();
mockRepo.Setup(...);
var controller = new HomeController(mockRepo.Object);

// Act
var result = await controller.Index();

この方法はお勧めしません.Moqの学習コストを除いては、Httpリクエストをシミュレートするほど実際の呼び出しシーンに近いものではないことが重要なので、本稿ではあまり紹介しません.このようなことがあればいいことを知っています.
転載先:https://www.cnblogs.com/willick/p/aspnetcore-unit-tests-with-xunit.html

fckeditor使用とエラー処理

Asp.Net中%=と%#の違い