単体テストの一般的な命名規則は何ですか？[閉まっている]

一般的な

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

例

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でメソッド名を終了する
• クラス名でメソッド名を開始する

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

• 各テストの状態を明確にします。
• 予想される動作について具体的。

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

レイの答えに反して、私はテスト接頭辞が必要だとは思いません。それはテストコードです。コードを識別するためにこれを行う必要がある場合は、より大きな問題が発生するので、テストコードを本番コードと混同しないでください。

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

そうは言っても、私はそれを使って自分の冒険をテストし、ブログに書くのはまだかなり新しいです:)

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

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

例えば

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

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

私はMethodName_DoesWhat_WhenTheseConditionsそのような慣例を使用する傾向があります：

Sum_ThrowsException_WhenNegativeNumberAs1stParam

ただし、私がよく目にするのは、テスト名を以下のユニットテスト構造に従うことです。

• アレンジ
• 行為
• 主張する

これは、次のBDD / Gherkin構文にも従います。

• 与えられた
• いつ
• その後

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

だからあなたの例に：

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

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

いずれにせよ、すべての単語ではなく、テスト名の主要なセクションをアンダースコアで区切るのが好きです。これにより、テストのポイントがわかりやすくなり、理解しやすくなります。

言い換えれば、私のように：Sum_ThrowsException_WhenNegativeNumberAs1stParamより良いですSum_Throws_Exception_When_Negative_Number_As_1st_Param。

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

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

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

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

不可能な例外やアクションをテストするメソッドの場合、テストメソッドの前に「できない」という単語を付けます。

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

私の命名規則は、ブライアンクックの記事「TDDヒント：テスト命名規則とガイドライン」に基づいています。この記事はとても役に立ちました。

CamelCasingは単語を分離し、下線は命名体系の一部を分離するため、最初の名前のセットは私には読みやすくなっています。

また、関数名、またはそれを囲む名前空間やクラスのどこかに "Test"を含める傾向があります。

あなたが単一の練習に従う限り、それは本当に問題ではありません。一般的に、私はメソッドのすべてのバリエーションをカバーするメソッドの単一の単体テスト（私は単純なメソッドがあります）を記述し、それを必要とするメソッドのより複雑なテストのセットを記述します。したがって、私の命名構造は通常テストです（JUnit 3からの引き継ぎ）。

テストの名前空間、クラス、メソッドには「T」プレフィックスを使用しています。

私はきちんと整理して、名前空間を複製するフォルダーを作成してから、テスト用のテストフォルダーまたは別のプロジェクトを作成し、基本的なテストの本番環境を複製します。

AProj
   Objects
      AnObj
         AProp
   Misc
      Functions
         AFunc
   Tests
      TObjects
         TAnObj
            TAnObjsAreEqualUnderCondition
      TMisc
         TFunctions
            TFuncBehavesUnderCondition

私は、何かがテストであることを簡単に確認できます。それが関連する元のコードを正確に知っています（それを解決できない場合、テストはとにかく複雑すぎます）。

インターフェースの命名規則と同じように見えます（つまり、「I」で始まるものと混同したり、「T」で混乱したりすることはありません）。

テストあり、またはなしでコンパイルするのは簡単です。

とにかく理論的には優れており、小規模なプロジェクトではかなりうまく機能します。