単体テストの命名のベストプラクティス[終了]

単体テストクラスとテストメソッドに名前を付けるためのベストプラクティスは何ですか？

これは以前にSOで議論されました、ユニットテストの一般的な命名規則は何ですか？

これが非常に優れたアプローチであるかどうかはわかりませんが、現在の私のテストプロジェクトでは、各プロダクションクラスとテストクラスの間で1対1のマッピングがProductありProductTestます。

私のテストクラスには、テストしているメソッドの名前、アンダースコア、そして状況と私が期待することを含むメソッドがありますSave_ShouldThrowExceptionWithNullName()。

私はロイオセロベの命名戦略が好きです。それは次のとおりです。

[UnitOfWork_StateUnderTest_ExpectedBehavior]

メソッド名と構造化された方法で必要なすべての情報があります。

作業単位は、単一のメソッド、クラスのように小さくすることも、複数のクラスのように大きくすることもできます。これは、このテストケースでテストされ、管理されるすべてのものを表す必要があります。

アセンブリの場合、私は典型的な.Testsエンディングを使用しますが、これは広く普及しており、クラス（で終わるTests）でも同じだと思います。

[NameOfTheClassUnderTestTests]

以前は、テストの代わりに接尾辞としてFixtureを使用していましたが、後者がより一般的であると考えて、命名戦略を変更しました。

テスト対象のユニット（つまりクラス）の後にテストフィクスチャに名前を付けるときは、テストの「Should」命名基準に従います。

説明するには（C＃とNUnitを使用）：

[TestFixture]
public class BankAccountTests
{
  [Test]
  public void Should_Increase_Balance_When_Deposit_Is_Made()
  {
     var bankAccount = new BankAccount();
     bankAccount.Deposit(100);
     Assert.That(bankAccount.Balance, Is.EqualTo(100));
  }
}

なぜ「すべき」なのか？

テストの作成者に、「[ある状態にあるべき] [後で/前に/いつにすべきか] [アクションが行われるべきである」という文に沿ってテストに名前を付けることを強制していることがわかりました

はい、どこにでも「Should」と書くことは少し繰り返しが多くなりますが、前述したように、ライターは正しい方法で考える必要があります（初心者には良いかもしれません）。加えて、それは一般的に読みやすい英語のテスト名になります。

更新：

Jimmy Bogardも「should」のファンであり、Shouldというユニットテストライブラリさえあることに気づきました。

アップデート（4年後...）

興味のある人のために、テストに名前を付ける私のアプローチは長年にわたって進化してきました。上記のShouldパターンの問題の1つは、どのメソッドがテスト中であるのかが一目でわかりにくいためです。OOPの場合、テスト対象のメソッドからテスト名を開始する方が理にかなっていると思います。適切に設計されたクラスの場合、これにより、テストメソッド名が読みやすくなります。現在、と同様の形式を使用しています<method>_Should<expected>_When<condition>。明らかにコンテキストによっては、Should / When動詞をより適切なものに置き換えたい場合があります。例： Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

私はこの命名スタイルが好きです：

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

等々。テスター以外の人に問題が何であるかを明確にします。

ケントベックは次のように提案しています。

• 「ユニット」（プログラムのクラス）ごとに1つのテストフィクスチャ。テストフィクスチャはクラス自体です。テストフィクスチャ名は次のようになります。

  [name of your 'unit']Tests
  

• テストケース（テストフィクスチャメソッド）の名前は次のとおりです。

  test[feature being tested]
  

たとえば、次のクラスがあるとします。

class Person {
    int calculateAge() { ... }

    // other methods and properties
}

テストフィクスチャは次のようになります。

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

クラス名。テストフィクスチャ名については、「テスト」が多くのドメインのユビキタス言語で非常に一般的であることがわかりました。たとえば、エンジニアリングドメインStressTestでは、化粧品ドメインではですSkinTest。Kentに同意できないことに申し訳ありませんが、テストフィクスチャ（StressTestTest？）で "Test"を使用すると混乱します。

「ユニット」は、ドメインでも多く使用されます。例えばMeasurementUnit。MeasurementUnitTest「Measurement」または「MeasurementUnit」のテストと呼ばれるクラスですか？

したがって、すべてのテストクラスに "Qa"プレフィックスを使用するのが好きです。例えばQaSkinTestとQaMeasurementUnit。ドメインオブジェクトと混同されることはありません。接尾辞ではなく接頭辞を使用すると、すべてのテストフィクスチャが視覚的に共存します（テストプロジェクトに偽物やその他のサポートクラスがある場合に役立ちます）。

名前空間。私はC＃で作業していて、テストクラスを、テストしているクラスと同じ名前空間に保持しています。個別のテスト名前空間を持つよりも便利です。もちろん、テストクラスは別のプロジェクトにあります。

メソッド名をテストします。私は自分のメソッドにWhenXXX_ExpectYYYという名前を付けたいです。それは前提条件を明確にし、自動化されたドキュメンテーション（la TestDox）に役立ちます。これはGoogleテストブログのアドバイスに似ていますが、前提条件と期待の分離が進んでいます。例えば：

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

私は「ギブン・ザーン・ザーン」という概念を使用しています。この短い記事http://cakebaker.42dh.com/2009/05/28/given-when-then/をご覧ください。記事ではBDDの観点からこの概念について説明していますが、TDDでも変更なしで使用できます。

見る： http //googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html

テストのメソッド名については、個人的には冗長で自己文書化された名前を使用すると非常に便利です（テストの内容を詳しく説明するJavadocコメントと一緒に）。

最も重要なことの1つは、命名規則に一貫している（そして、チームの他のメンバーと同意する）ことだと思います。同じプロジェクトでさまざまな規則が使用されているのを何度も目にします。

私は最近、説明を最大化するために、テスト、クラス、およびプロジェクトを含むための次の規則を思いつきました。

名前空間のSettingsプロジェクトのクラスをテストしているとしましょうMyApp.Serialization。

まず、MyApp.Serialization.Tests名前空間を使用してテストプロジェクトを作成します。

このプロジェクト内、そしてもちろん名前空間内にIfSettings（IfSettings.csとして保存された）というクラスを作成します。

SaveStrings()メソッドをテストしているとしましょう。->テストに名前を付けますCanSaveStrings()。

このテストを実行すると、次の見出しが表示されます。

MyApp.Serialization.Tests.IfSettings.CanSaveStrings

これは、それが何をテストしているかを非常によく教えてくれると思います。

もちろん、英語では名詞「Tests」が動詞「tests」と同じであることは有用です。

テストに名前を付ける際の創造性に制限はないので、テストの全文見出しを取得できます。

通常、テスト名は動詞で始まる必要があります。

例は次のとおりです。

• 検出（例DetectsInvalidUserInput）
• スロー（例ThrowsOnNotFound）
• 意志（例WillCloseTheDatabaseAfterTheTransaction）

等

別のオプションは、「if」の代わりに「that」を使用することです。

後者は私にキーストロークを保存し、テストされた動作が存在することを知らないので、私が何をしているかをより正確に説明しますが、存在するかどうかをテストしています。

[ 編集 ]

上記の命名規則をもう少し長く使用した後、インターフェースを操作するときに、Ifプレフィックスが混乱する可能性があることがわかりました。テストクラスIfSerializer.csが[ファイルを開く]タブのISerializer.csインターフェースに非常に似ていることが偶然に起こります。これは、テスト、テスト対象のクラス、およびそのインターフェースの間で切り替えを行うときに非常に煩わしくなります。その結果、私は今、選ぶだろうそれを超える場合は接頭辞として。

さらに、次のように、テストメソッド名の単語を区切るために、「_」を使用します。

[Test] public void detects_invalid_User_Input()

これは読みやすいと思います。

[ 編集を終了 ]

テストが何であるかを理解するために費やしていたはずの多くの時間を節約できるので、テストに名前を付けることを非常に重要視することを検討しているので、これによりいくつかのアイデアが生まれることを願っています（たとえば、長期間の活動停止後にプロジェクトを再開した後） 。

VS + NUnitでは、通常、プロジェクトにフォルダーを作成して、機能テストをグループ化します。次に、単体テストフィクスチャクラスを作成し、テストする機能の種類に基づいて名前を付けます。[Test]メソッドは、次のように名前が付けられていますCan_add_user_to_domain。

- MyUnitTestProject   
  + FTPServerTests <- Folder
   + UserManagerTests <- Test Fixture Class
     - Can_add_user_to_domain  <- Test methods
     - Can_delete_user_from_domain
     - Can_reset_password

テストを同じパッケージ内に、テスト対象のソースの並列ディレクトリに保持することで、多数の除外パターンを実行する必要がなく、コードを展開する準備ができたら、コードの肥大化を解消できます。

「JUnitポケットガイド」で説明されているベストプラクティスが個人的に気に入っています。JUnitの共著者が書いた本に勝るものはありません。

クラスFooのテストケースの名前は、FooTestCaseまたはそれに類するもの（FooIntegrationTestCaseまたはFooAcceptanceTestCase）である必要があります。これはテストケースであるためです。テスト、テストケース、テストフィクスチャ、テストメソッドなどの標準的な命名規則については、http：//xunitpatterns.com/を参照してください。