unit-testing - 単体テストの命名規則を変更する必要がありますか?

Question

現在、単体テストには単純な規則を使用しています。「EmployeeReader」という名前のクラスがある場合、「EmployeeReader.Tests」という名前のテストクラスを作成します。次に、次のような名前でテストクラスのクラスのすべてのテストを作成します。

Reading_Valid_Employee_Data_Correctly_Generates_Employee_Object
Reading_Missing_Employee_Data_Throws_Invalid_Employee_ID_Exception

等々。

私は最近、BDD で使用される別の種類の命名規則について読んでいます。このネーミングの読みやすさが気に入っています。最終的には、次のようなテストのリストになります。

When_Reading_Valid_Employee (フィクスチャ)
- Employee_Object_Is_Generated (メソッド)
- Employee_Has_Correct_ID (メソッド)
When_Reading_Missing_Employee (フィクスチャ)
- An_Invalid_Employee_ID_Exception_Is_Thrown (メソッド)

等々。

両方の命名スタイルを使用した人はいますか? 次のプロジェクトに切り替えるかどうかを判断するのに役立つアドバイス、利点、欠点、落とし穴などを提供してもらえますか?

score 3 · Accepted Answer

2 番目の例 (クラスごとに 1 つではなく、論理的な「タスク」ごとにフィクスチャを使用する) には、タスクごとに異なる SetUp および TearDown ロジックを使用できるという利点があります。これにより、個々のテストメソッドが簡素化され、読みやすくなります。

どちらか一方を標準として決める必要はありません。各クラスでテストする必要がある「タスク」の数に応じて、両方を組み合わせて使用します。

score 2 · Accepted Answer

行が長くなるとコードが読みづらくなったり、ざっと目を通しにくくなったりするため、2 番目の方が優れていると思います。テストが何をするかについてまだ曖昧な点があると思われる場合は、コメントを追加して明確にすることができます。

score 1 · Accepted Answer

私は2番目の方法を使用しますが、これはソフトウェアが何をすべきかを説明するのに非常に役立ちます。また、ネストされたクラスを使用して、より詳細なコンテキストを記述します。

本質的に、テストクラスはネスト可能なコンテキストであり、メソッドはすべて1行のアサーションです。例えば、

public class MyClassSpecification
{
    protected MyClass instance = new MyClass();

    public class When_foobar_is_42 : MyClassSpecification 
    {
        public When_foobar_is_42() {
            this.instance.SetFoobar( 42 ); 
        }

        public class GetAnswer : When_foobar_is_42
        {
            private Int32 result;

            public GetAnswer() {
                this.result = this.GetAnswer();
            }

            public void should_return_42() {
                Assert.AreEqual( 42, result );
            }
        }
    }
}

これにより、テストランナーで次の出力が得られます。

MyClassSpecification+When_foobar_is_42+GetAnswer
    should_return_42

score 1 · Accepted Answer

あなたが参照している 2 番目の命名規則の背後にある理由の一部は、テストと動作仕様を同時に作成しているということです。物事が起こっている状況と、その状況の中で実際に何が起こるべきかを確立します。（私の経験では、観察/テスト方法は「should_」で始まることが多いため、標準の「When_the_invoicing_system_is_told_to_email_the_client」、「should_initiate_connection_to_mail_server」形式になります。）

テストフィクスチャを反映し、適切にフォーマットされた HTML スペックシートを出力し、アンダースコアを削除するツールがあります。最終的には、実際のコードと同期した人間が判読できるドキュメントになります (テストカバレッジを高く正確に保つ限り)。

作業しているストーリー/機能/サブシステムに応じて、これらの仕様は、特にアジャイルと BDD の中心である検証とフィードバックのために、プログラマー以外の利害関係者に示され、理解される可能性があります。

score 1 · Accepted Answer

私はあなたの質問で説明した2つの道と他のいくつかの道をたどってきました...最初の選択肢は非常に簡単で、ほとんどの人にとって理解しやすいものです。個人的には、BDD スタイル (2 番目の例) の方が好きです。異なるコンテキストを分離し、それらのコンテキストで観測をグループ化するからです。唯一の本当の欠点は、より多くのコードが生成されることです。そのため、きちんとしたテストが表示されるまでは、少し面倒に感じます。また、継承を使用してフィクスチャのセットアップを再利用する場合は、継承チェーンを出力するテストランナーが必要です。クラス「An_empty_stack」を考えて、それを再利用したいので、別のクラスを実行します。

score 0 · Accepted Answer

0

テストケースクラスを呼び出すことに投票します。

于 2009-07-03T04:47:04.957 に答える

unit-testing - 単体テストの命名規則を変更する必要がありますか?

7 に答える 7

Related

Reference