web-dev-qa-db-ja.com

単体テストの一般的な命名規則は何ですか？

全般

  • すべてのテストで同じ基準に従ってください。
  • 各テスト状態が何であるかを明確にしてください。
  • 予想される動作について具体的に説明してください。

例

1）MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

出典： 単体テストの命名基準

2）アンダースコアによる各単語の分離

Public void Sum_Negative_Number_As_1st_Param_Exception_Thrown() 

Public void Sum_Negative_Number_As_2nd_Param_Exception_Thrown () 

Public void Sum_Simple_Values_Calculated ()

その他

  • Testでメソッド名を終了
  • クラス名でメソッド名を開始
unit-testingnaming-conventions
202
stung

私はこの一人の男についてあなたとほとんど一緒です。使用した命名規則は次のとおりです。

  • 各テスト状態について明確にします。
  • 予想される動作について特定。

テスト名にはさらに何が必要ですか？

Ray's answer に反して、Testプレフィックスは必要ないと思います。それはテストコードです、私たちはそれを知っています。コードを識別するためにこれを行う必要がある場合は、より大きな問題が発生します。テストコードを本番コードと混同しないでください。

アンダースコアの長さと使用に関しては、そのテストコード、誰が気にしますか？読みやすく、テストが何をしているかが明確である限り、あなたとあなたのチームだけがそれを見るでしょう。 :)

とは言うものの、私はまだテストとテストが初めてです 冒険をブログに書いています :)

92
Rob Cooper

これも読む価値があります： 構造化単体テスト

構造には、テストされるクラスごとにテストクラスがあります。それはそれほど珍しいことではありません。しかし、私にとって珍しいのは、テスト対象のメソッドごとにネストされたクラスがあったことです。

例えば.

using Xunit;

public class TitleizerFacts
{
    public class TheTitleizerMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void Name_AppendsTitle()
        {
            // Test code
        }
    }

    public class TheKnightifyMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void MaleNames_AppendsSir()
        {
            // Test code
        }

        [Fact]
        public void FemaleNames_AppendsDame()
        {
            // Test code
        }
    }
}

理由は次のとおりです。

1つには、テストを整理するのに良い方法です。メソッドのすべてのテスト（またはファクト）はグループ化されます。たとえば、CTRL + M、CTRL + Oショートカットを使用してメソッド本体を折りたたむと、テストを簡単にスキャンしてコードの仕様のように読み取ることができます。

私もこのアプローチが好きです：

MethodName_StateUnderTest_ExpectedBehavior

だからおそらく調整する：

StateUnderTest_ExpectedBehavior

各テストは既にネストされたクラスにあるため

35
Robs

私はMethodName_DoesWhat_WhenTheseConditionsの規則を使用する傾向があるので、例えば：

Sum_ThrowsException_WhenNegativeNumberAs1stParam

しかし、私がよく見ているのは、テスト名を

  • アレンジ
  • 行為
  • アサート

また、次のBDD/Gherkin構文に従います。

  • 与えられた
  • いつ
  • それから

次の方法でテストに名前を付けることになります：UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

あなたの例に：

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

ただし、テストをアルファベット順に配置するか、VisStudioのメンバードロップダウンボックスにアルファベット順に表示することができ、1つのメソッドのすべてのテストがグループ化されるため、テストするメソッド名を最初に置くことをお勧めします。

いずれの場合も、テスト名のメジャーセクションをアンダースコアで区切るのが好きです。すべてのWordではなく、読みやすくポイントを取得しやすいと思うからですテスト全体。

つまり、Sum_ThrowsException_WhenNegativeNumberAs1stParamはSum_Throws_Exception_When_Negative_Number_As_1st_Paramよりも優れています。

26
CodingWithSpike

テストメソッドには、アンダースコアやセパレータなしで「PascalCasing」を使用する他のメソッドと同じように名前を付けます。メソッドのpostfixTestはそのままにしておきます。値が追加されないためです。メソッドがテストメソッドであることは、属性TestMethodで示されます。

[TestMethod]
public void CanCountAllItems() {
  // Test the total count of items in collection.
}

各テストクラスは他の1つのクラスのみをテストする必要があるため、クラス名はメソッド名から除外します。テストメソッドを含むクラスの名前は、「Tests」という接尾辞が付いたテスト対象のクラスのような名前になります。

[TestClass]
public class SuperCollectionTests(){
    // Any test methods that test the class SuperCollection
}

例外または不可能なアクションをテストするメソッドの場合、テストメソッドの先頭にWordCannotを付けます。

[TestMethod]
[ExpectedException(typeOf(ArgumentException))]
public void CannotAddSameObjectAgain() {
  // Cannot add the same object again to the collection.
}

私の命名規則は、Bryan Cookの記事 "TDD Tips：命名規則とガイドラインのテスト" に基づいています。この記事はとても役に立ちました。

22
Jehof

CamelCasingは単語を分離し、アンダーバーは命名スキームの部分を分離するため、最初の名前のセットは読みやすいです。

また、関数名またはそれを囲む名前空間またはクラスのいずれかに「テスト」を含める傾向があります。

5
Frank Szczerba