208

全般的

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

例

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

7 に答える 7

98

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

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

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

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

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

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

于 2008-09-18T20:32:48.137 に答える
38

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

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

例えば

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

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

于 2012-01-21T18:35:16.607 に答える
30

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.

于 2012-02-15T18:20:19.490 に答える
22

アンダースコアや区切り記号を使用せずに「PascalCasing」を使用して、他のメソッドと同様にテストメソッドに名前を付けます。メソッドの接尾辞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
}

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

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

私の命名規則は、Bryan Cookの記事「TDD Tips: Test Naming Conventions & Guidelines」に基づいています。この記事はとても役に立ちました。

于 2009-08-18T06:40:59.763 に答える
5

CamelCasingは単語を分離し、アンダーバーは命名スキームの一部を分離するため、最初の名前のセットは私にとってより読みやすくなっています。

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

于 2008-09-18T20:04:52.870 に答える
-3

あなたが単一の慣習に従う限り、それは実際には重要ではありません。一般に、私はメソッドのすべてのバリエーションをカバーするメソッドの単一の単体テストを作成し（私は単純なメソッドを持っています;）、それを必要とするメソッドのより複雑なテストのセットを作成します。したがって、私の命名構造は通常テストです（JUnit 3からのホールドオーバー）。

于 2008-09-18T20:04:47.800 に答える
-7

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

名前空間をレプリケートするフォルダーをきちんと作成してから、tests フォルダーまたはテスト用の別のプロジェクトを作成し、基本的なテストの運用構造をレプリケートします。

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

何かがテストであることは簡単にわかります。元のコードがどのようなものであるかは正確にわかっています (それがうまくいかない場合は、とにかくテストが複雑すぎます)。

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

テストの有無にかかわらず、コンパイルするのは簡単です。

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

于 2011-01-07T03:56:20.457 に答える