単体テスト命名のベストプラクティス
単体テストクラスとテストメソッドに名前を付けるためのベストプラクティスは何ですか？
これは以前にSOで議論されました。 ユニットテストでよく使われている命名規則は何ですか？
これが非常に良いアプローチであるかどうかはわかりませんが、現在の私のテストプロジェクトでは、各プロダクションクラスとテストクラスの間に1対1のマッピングがあります。 ProductとProductTest。
私のテストクラスには、私がテストしているメソッドの名前、アンダースコア、そして状況と私が予想していることを含むメソッドがあります。 Save_ShouldThrowExceptionWithNullName()。
私は Roy Osheroveの命名戦略 が好きです。それは次のとおりです。
[UnitOfWork_StateUnderTest_ExpectedBehavior]
メソッド名や構造化された方法で必要なすべての情報が含まれています。
作業単位は、単一のメソッド、クラス、または複数のクラスと同じくらい小さくすることができます。それは、このテストケースでテストされるべきものであり、制御下にあるものすべてを表すべきです。
アセンブリには、一般的な.Testsエンディングを使用します。これは、クラスでも非常に広範囲に渡って同じであると思います（Testsで終わる）。
[NameOfTheClassUnderTestTests]
以前はテストの代わりにフィクスチャをサフィックスとして使用しましたが、後者の方が一般的であると思うので、命名方法を変更しました。
私は "Should" の命名基準に従うことを好む test 命名しながら test fixture 被試験単位（すなわちクラス）の後.
説明するには（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();
等々。それは問題が何であるか非テスターに本当に明らかにします。
Kent Beck は次のように示唆しています。
'unit'（あなたのプログラムのクラス）ごとに一つのテストフィクスチャ。テストフィクスチャはクラスそのものです。テストフィクスチャ名は次のようになります。
[name of your 'unit']Testsテストケース（テストフィクスチャメソッド）の名前は次のとおりです。
test[feature being tested]
たとえば、次のようなクラスがあります。
class Person {
int calculateAge() { ... }
// other methods and properties
}
テストフィクスチャは次のようになります。
class PersonTests {
testAgeCalculationWithNoBirthDate() { ... }
// or
testCalculateAge() { ... }
}
クラス名テストフィクスチャの名前については、 "Test"が多くのドメインのユビキタス言語ではかなり一般的であることがわかりました。たとえば、エンジニアリング分野では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
私はGiven-When-Thenという概念を使います。この短い記事 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つはあなたの命名規則で一貫していることです（そしてあなたのチームの他のメンバーとそれに同意します）。多くの場合、私は同じプロジェクトでさまざまな規則が使われているのを目にします。
私は最近、私のテスト、それらのクラスに名前を付け、それらの記述を最大にするためにプロジェクトを含むために以下の規約を思いつきました：
MyApp.Serialization名前空間のプロジェクトでSettingsクラスをテストしているとしましょう。
最初に、MyApp.Serialization.Tests名前空間を使用してテストプロジェクトを作成します。
このプロジェクトともちろん名前空間の中で私はIfSettingsと呼ばれるクラスを作成します（IfSettings.csとして保存されます）。
SaveStrings（）メソッドをテストしているとしましょう。 - >テストに名前を付けますCanSaveStrings（）。
このテストを実行すると、次の見出しが表示されます。
MyApp.Serialization.Tests.IfSettings.CanSaveStrings
私はこれが私に非常によくわかります、それがテストしているものであると思います。
もちろん、英語の名詞 "Tests"が動詞 "tests"と同じであることは有用です。
テストの命名にあなたの創造性に制限はないので、私たちはそれらに完全な文の見出しを得ます。
通常、テスト名は動詞で始める必要があります。
例は次のとおりです。
- 検出（例DetectsInvalidUserInput）
- スロー（ThrowsOnNotFoundなど）
- Will（例：WillCloseTheDatabaseAfterTheTransaction）
等.
別の選択肢は、 "if"の代わりに "that"を使用することです。
後者は、私のキーストロークを節約し、私がしていることをより正確に説明します。なぜなら、thatテストした動作は存在しますが、テストしていますならそうです。
[編集]
上記の命名規則をもう少し長く使用した後、インターフェイスを操作するときに、If接頭辞が混乱を招く可能性があることがわかりました。テストクラスIfSerializer.csは、「オープンファイル」のインタフェースISerializer.csと非常によく似ています。タブ"。テスト、テストされているクラス、そしてそのインタフェースの間で行ったり来たりするとき、これは非常に面倒になることがあります。結果として、私はプレフィックスとしてThatIfを選択します。
また、テストクラスのメソッドにのみ使用します。他の場所ではベストプラクティスとは見なされていません。テストメソッド名の単語を区切るための "_"は、次のようになります。
- [テスト] public void detect_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 Pocket Guide" で説明されているベストプラクティスを気に入っています... JUnitの共著者によって書かれた本に勝るのは難しいです！
クラスFooのテストケースの名前は、FooTestCaseまたはそれに類するもの（FooIntegrationTestCaseまたはFooAcceptanceTestCase）である必要があります。これはテストケースなのでです。テスト、テストケース、テストフィクスチャ、テスト方法などの標準命名規則については、 http://xunitpatterns.com/ を参照してください。