4

多くの状況で、クラスとメソッドの適切な単体テスト名を思いつくのが困難です。通常、私は次の形式に従うようにしています。

public class TestContext
{
    [Fact]
    public void WhenThis_DoThat()
    {
    }
}

明確にするために、Given、When、Then という単語をパーツに付ける人もいます。単体テストが何をテストしているのかをより明確にするように見えるので、私はそれが好きです。BDD ツールキットを検討する以外に、これが単純な古い xUnit ツールでどのように機能するかについてアドバイスが必要です。

次のようなシナリオでは特に苦労しています。

アプリケーションが起動すると、メイン フォームが読み込まれ、ユーザーがクリックできるリンクのリストが表示されます。

または、より良いユースケースのシナリオは次のとおりです。

ユーザーは、リンクのリストからリンクを選択できます。

確かではありませんが、アプリを実行し、フォームにクリック可能なリンクのリストが読み込まれる動作を説明しようとしています。そして、それを単体テストに変えます。

そのための与えられた、いつ、そしてその後は何ですか？

4

5 に答える 5

6

これが私がBDD仕様スタイルでテストを書く方法です：http：//github.com/orfjackal/tdd-tetris-tutorial

必要なのは、1つのクラスに複数のテストフィクスチャを含める機能です。次に、各フィクスチャが「Given / When」部分であり、各テストメソッドが「Then」部分であるようにテストを編成することができます。JUnitはそれをサポートしていないので、私はそれのための簡単なテストランナーを書きました：

@RunWith(NestedJUnit4.class)
public class WerewolfTest extends Assert {
    public class Given_the_moon_is_full {
        @Before public void When_you_walk_in_the_woods() {
            ...
        }
        @Test public void Then_you_can_hear_werewolves_howling() {
            ...
        }
        @Test public void Then_you_wish_you_had_a_silver_bullet() {
            ...
        }
    }
    public class Given_the_moon_is_not_full {
        @Before public void When_you_walk_in_the_woods() {
            ...
        }
        @Test public void Then_you_do_not_hear_any_werewolves() {
            ...
        }
        @Test public void Then_you_are_not_afraid() {
            ...
        }
    }
}
于 2009-10-05T20:40:07.537 に答える
4

Dan North のBDD の紹介を引用します。

テストメソッド名は文にする必要があります

初めての「あはは！」その瞬間は、同僚の Chris Stevenson が作成したagiledoxという一見単純なユーティリティを見せられたときに起こりました。JUnit テスト クラスを取得し、メソッド名をプレーンな文として出力するため、テスト ケースは次のようになります。

public class CustomerLookupTest extends TestCase { testFindsCustomerById() { ... } testFailsForDuplicateCustomers() { ... } ... }

次のようなものをレンダリングします。

CustomerLookup – finds customer by id – fails for duplicate customers – ...

クラス名とメソッド名の両方から「test」という単語が削除され、キャメルケースのメソッド名が通常のテキストに変換されます。たったこれだけですが、その効果は絶大です。

開発者は、ドキュメントの少なくとも一部を作成できることを発見したため、実際の文章であるテスト メソッドを書き始めました。さらに、ビジネス ドメインの言語でメソッド名を記述すると、生成されたドキュメントがビジネス ユーザー、アナリスト、およびテスト担当者にとって意味のあるものになることがわかりました。

論文全体は実際に読む価値があります。熱烈おすすめ！

于 2009-10-06T00:03:21.647 に答える
0

私は Roy Osherove のアプローチに従おうとしています:

http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx

于 2009-10-05T19:37:04.407 に答える
0

あなたのシナリオでは、何が問題になる可能性がありますか? 単体テストは何かをテストする必要があるため、何をテストしていますか。

FormHasLinks?

ロードフォーム? //次に、リンクをチェックします

たぶん、何をしているのかではなく、何をテストしているのかを言うと、簡単にわかるかもしれません。

于 2009-10-05T19:37:25.073 に答える
0

出力ではなく、入力にちなんでテストに名前を付けます。テストされているシナリオについて説明します。テスト ケースの名前で、そのシナリオで必要な出力が何であるかを定義しようとはしません。

たとえば、次の例では、さまざまなシナリオで、テキスト エディターで Backspace キーの動作をテストします。

  • スペースの後にバックスペース
  • インライン textrun の端の周りのバックスペース
  • 段落の先頭でバックスペース
  • 行末近くのバックスペース
  • 段落内でバックスペースを正規化する
  • 選択した単語と両方のスペースをバックスペースします
  • 選択した単語とスペースをバックスペースします
  • 選択した単語をバックスペース
  • バックスペース選択が 2 つの段落にまたがる
  • いくつかの単語をバックスペースします
  • バックスペースと選択した単語
  • 他のブロックの遠端へのバックスペース

したがって、どのシナリオがテストされているかを多かれ少なかれ確認できます (ただし、各シナリオで予想される動作が何であるかを示すこともありません)。

于 2009-10-05T20:28:03.740 に答える