2

私は単体テストの概念に非常に慣れていないため、最初の概念を書き続けています。

ID値を正規化する方法があります。正の数値 (内部に数値を含む文字列であっても) の場合は渡された値を返し、その他の渡された値の場合はゼロ (0) を返す必要があります。

function normalizeId($val) {
    // if $val is good positive number return $val;
    // else return 0;
}

この関数の単体テストを作成し、可能な引数をアサーションしたいと考えています。例: 5, -5, 0, "5", "-5", 3.14, "fff", new StdClass()など。

この条件のいずれかに対して TestCase クラスにメソッドを記述する必要がありますか?それとも、すべての条件を別々の行に 1 つのメソッドで記述する必要がありますか? いえ

public function testNormalizeId() {
    $this->assertEquals(5, MyClass::normalizeId(5));
    $this->assertEquals(0, MyClass::normalizeId(-5));
    $this->assertEquals(0, MyClass::normalizeId("fff"));
}

また

public function testNormalizeId_IfPositiveInt_GetPositiveInt() {
    $this->assertEquals(5, MyClass::normalizeId(5));
}
public function testNormalizeId_IfNegativeInt_GetZeroInt() {
   $this->assertEquals(0, MyClass::normalizeId(-5));
}
public function testNormalizeId_IfNotIntAsString_GetZeroInt() {
    $this->assertEquals(0, MyClass::normalizeId("fff"));
}

ベストプラクティスはどうですか？2 番目の選択肢が良いと聞きましたが、非常に多くの可能なパラメーター値に対して非常に多くのメソッドが存在することを心配しています。正の数、負の数、ゼロ、内部に正の数を含む文字列、内部に負の数を含む文字列、内部に浮動小数点数を含む文字列などを指定できます。

編集

または多分3番目のアプローチprovider？

public function testNormalizeIdProvider()
{
    return array(
        array(5, 5),
        array(-5, 0),
        array(0, 0),
        array(3.14, 0),
        array(-3.14, 0),
        array("5", 5),
        array("-5", 0),
        array("0", 0),
        array("3.14", 0),
        array("-3.14", 0),
        array("fff", 0),
        array("-fff", 0),
        array(true, 0),
        array(array(), 0),
        array(new stdClass(), 0),
    );
}

/**
 * @dataProvider testNormalizeIdProvider
 */
public function testNormalizeId($provided, $expected)
{
    $this->assertEquals($expected, MyObject::normalizeId($provided));
}
4

2 に答える 2

2

私はPHPやそこで使用できる単体テストフレームワークについてあまり詳しくありませんが、単体テストの一般的な分野では、これらの理由から2番目のアプローチをお勧めします

  • どのテスト ケースが失敗したかを特定するために実際の Assert 失敗メッセージをトロールするのではなく、特定のタイプの入力に対して特定のテスト ケースが失敗するようにします。

  • 複数の入力を使用して特定のタイプの変換でテストを実行する必要があると判断した場合 (たとえば、1,000 個のランダムな文字列を含むテキスト ファイルを作成し、これらをドライバーをテストし、後で機能テストまたは受け入れテストによって各エントリの文字列を変換するためのテスト ケースを実行します)。

  • セットアップに特別なロジックが必要な場合に、個々のテスト ケースを簡単に変更できます。

  • メソッド名がチェックリストに照らして簡単に読み取れるため、変換のタイプを見逃したときに見つけやすくなります:)

  • （疑わしい）特定のタイプの変換を実行するために個別のサブクラスを使用するために、「神のクラス」が内部リファクタリングを必要とする場所を見つけやすくなるでしょう（アプローチが間違っているとは言いませんが、1つのロジックを見つけるかもしれません変換のタイプは非常に厄介です; 20 または 30 の個々のテスト ケースを確認すると、弾丸をかじり、より専門的なコンバーター クラスを開発するきっかけになる可能性があります)

それが役立つことを願っています。

于 2013-10-22T19:52:05.680 に答える