1

炎上するリスクがあります...コンテキストが暗黙的であるコンテキストで、関数ではなくメソッドへの呼び出しを強制することにはどのような利点がありますか。

PHPの構文がメソッドを呼び出すのに非常に醜いことを考えると、なぜPHPUnitの作成者はその使用法を強制したのでしょうか。

フレームワークがグローバルな「currentTestCase」オブジェクトを設定し、そのオブジェクトに透過的に関連付けられた失敗したアサートがあった場合、次のように記述できます。

assertEquals("blah", $text);

同等の、しかし冗長なものとは対照的に：

$this->assertEquals("blah", $text);

このコンテキストでOOを使用すると、正確に何が得られますか。

教えてください。

4

4 に答える 4

6

PHPUnitはxUnitから派生しているため、xUnitはそれを実行します。

なぜxUnitはそれをそのようにするのですか？よろしくお願いします。Robertが指摘するように、元々の理由は、xUnitがSmalltalkに由来し、JavaのJUnitによって普及したことです。どちらもOO-or-nothing言語であるため、選択の余地はありませんでした。

これは、他の利点がないということではありません。OOテストは継承できます。これは、サブクラスをテストする場合は、すべての親のテストを実行し、変更した動作のいくつかのテストメソッドをオーバーライドできることを意味します。これにより、テストコードを複製することなく、サブクラスの優れたカバレッジが得られます。

PHPUnitでassertメソッドを簡単に追加およびオーバーライドできます。サブクラスPHPUnit_Framework_TestCaseを作成し、独自のassertメソッドを作成して、テストクラスに新しいサブクラスを継承させます。setupデフォルトとteardownメソッドを作成することもできます。

最後に、テストフレームワークのメソッドがテスト対象のものと衝突しないことを保証します。テストフレームワークがその関数をテストにダンプしたばかりで、メソッドを持つものをテストしたいsetup場合は...問題が発生しています。

そうは言っても、あなたの痛みが聞こえます。大きなテストフレームワークは、煩わしく、面倒で、もろい場合があります。PerlはxUnitスタイルを使用せず、短いテスト関数名を持つ手続き型スタイルを使用します。例については、 Test::Moreを参照してください。舞台裏では、あなたが提案したとおりに動作します。すべての関数が使用するシングルトンテストインスタンスオブジェクトがあります。Test::Classと呼ばれるOOテストメソッドモジュールを備えたハイブリッドプロシージャアサーション関数もあります。これは両方の長所を発揮します。

PHPの構文がメソッドの呼び出しに非常に醜いことを考えると

私はあなたが好きではないと思います->。私はあなたがそれと一緒に暮らすことを学ぶことをお勧めします。OO PHPは、他の方法よりもはるかに優れています。

于 2009-06-01T20:35:23.427 に答える
3

理由の1つはassertXXX、メソッド名が名前の衝突のリスクが高いことです。

もう1つは、 xUnitファミリーから派生したもので、通常はオブジェクト指向言語（最初はSmalltalk）を扱います。これにより、JavaやRubyなどの「兄弟」との関係を築きやすくなります。

于 2009-06-01T20:20:27.793 に答える
2

直接的な答えではありませんが、PHPUnit 3.5以降、$this->もう書く必要はありません。PHPUnit 3.5は、アサーション用の関数ライブラリを追加しました。これを含める必要があります

require_once 'PHPUnit/Framework/Assert/Functions.php';

その後、あなたはすることができます

assertEquals('foo', $bar);

それについてはSebastianBergmannのブログ投稿を参照してください

于 2010-10-07T11:39:05.940 に答える
0

クラスメソッドにテストケースを含めると、PHPUnitの作業が節約されます。組み込みのインテリジェンスがないため、PHPUnitは純粋なテスト関数を見つけたり処理したりできませんでした。-> assert *（）メッセージを-単純なブールチェーンで-認識するだけで、処理ロジックが再び節約されます（PHPUnitの場合、テストケースの作成者ではありません）。PHPUnit / SimpleTestの観点からオーバーヘッドを節約するのは、すべて構文上のソルトです。

エラー/警告メッセージ、例外をキャプチャしたり、PHPのネイティブassert（）ステートメントを認識したりすることは技術的な問題ではありません。難しいAPIはよりエンタープライズに見えるため、これは実行されません。

于 2010-10-07T05:23:16.000 に答える