unit-testing - ユニットテストの命名のベストプラクティス

Question

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

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

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

次に、テストクラスに、テストしているメソッドの名前、アンダースコア、状況、および予想される結果を含むメソッドがありますSave_ShouldThrowExceptionWithNullName()。

score 607 · Accepted Answer

更新 (2021 年 7 月)

私の最初の回答 (ほぼ 12 年) からかなりの時間が経過しており、この間にベストプラクティスが大きく変化しています。そのため、私は自分の回答を更新し、読者にさまざまな命名戦略を提供したいと思っています.

多くのコメントと回答は、私が最初の回答で提案した命名戦略はリファクタリングに耐性がなく、名前を理解するのが難しいことを指摘しており、私は完全に同意します.

ここ数年、 Vladimir Khorikovによって記述された行で、テスト名がテストしたいものを説明する、より人間が読める命名スキーマを使用することになりました。

いくつかの例は次のとおりです。

Add_credit_updates_customer_balance
Purchase_without_funds_is_not_possible
Add_affiliate_discount

しかし、ご覧のとおり、非常に柔軟なスキーマですが、最も重要なことは、時間の経過とともに変化する可能性のある技術的な詳細を含めずに、名前を読んでテストの内容を理解できることです。

プロジェクトとテストクラスに名前を付けるには、元の回答スキーマを引き続き使用します。

元の回答 (2009 年 10 月)

Roy Osherove の命名戦略が好きです。それは次のとおりです。

[UnitOfWork_StateUnderTest_ExpectedBehavior]

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

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

アセンブリの場合、私は典型的な.Tests末尾を使用します。これは非常に広く普及していると思いますが、クラスでも同じです (末尾はTests):

[NameOfTheClassUnderTestTests]

以前は、Tests ではなく Fixture をサフィックスとして使用していましたが、後者の方が一般的だと思い、命名戦略を変更しました。

score 89 · Accepted Answer

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

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

等々。問題が何であるかを非テスターに本当に明確にします。

score 56 · Accepted Answer

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

「ユニット」 (プログラムのクラス) ごとに 1 つのテストフィクスチャ。テストフィクスチャはクラスそのものです。テストフィクスチャ名は次のようになります。
```
[name of your 'unit']Tests
```
テストケース (テストフィクスチャメソッド) には、次のような名前があります。
```
test[feature being tested]
```

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

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

    // other methods and properties
}

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

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

score 19 · Accepted Answer

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

「ユニット」もドメインでよく使われます。例MeasurementUnit。MeasurementUnitTest「Measurement」または「MeasurementUnit」のテストと呼ばれるクラスですか?

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

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

メソッド名をテストします。メソッドに WhenXXX_ExpectYYY という名前を付けるのが好きです。前提条件を明確にし、自動化されたドキュメント (TestDox 風) に役立ちます。これは、Google テストブログのアドバイスに似ていますが、前提条件と期待がより分離されています。例えば：

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

score 14 · Accepted Answer

Given-When-Then の概念を使用します。この短い記事http://cakebaker.42dh.com/2009/05/28/given-when-then/をご覧ください。この記事では、この概念を BDD の観点から説明していますが、TDD でも変更なしで使用できます。

score 10 · Accepted Answer

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

名前空間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と非常によく似ています。これは、テスト、テスト対象のクラス、およびそのインターフェイスの間を行ったり来たりするときに非常に煩わしくなります。その結果、接頭辞としてIfではなくThatを選択するようになりました。

さらに、他の場所ではベストプラクティスとは見なされないため、テストクラスのメソッドに対してのみ使用します。次のように、テストメソッド名の単語を区切るために「_」を使用します。

[Test] public void detects_invalid_User_Input()

こちらの方が読みやすいと思います。

【編集終了】

テストに名前を付けることが非常に重要であると考えているため、これによりいくつかのアイデアが生まれることを願っています。これにより、テストが何をしているのかを理解するために費やされていた時間を大幅に節約できるためです (たとえば、長期間の中断後にプロジェクトを再開した後)。 .

score 9 · Accepted Answer

参照: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsively.html

テストメソッドの名前については、個人的には冗長で自己文書化された名前を使用することが非常に便利だと思います (テストが何を行っているかをさらに説明する Javadoc コメントと共に)。

score 7 · Accepted Answer

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

score 2 · Accepted Answer

テストを同じパッケージに保持するが、テスト対象のソースとは並列のディレクトリに保持することで、一連の除外パターンを実行することなく、デプロイの準備ができたらコードの肥大化を排除できることを付け加えておきます。

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

score 2 · Accepted Answer

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

unit-testing - ユニットテストの命名のベストプラクティス

11 に答える 11

Related

Reference