1

私はPHPUnitを初めて使用します。実際、今日から始めました。そして、私が読んでいる限り、このスクリプトが何をするかだけを理解するようになりました.

class UserTest extends PHPUnit_Framework_TestCase
{
     protected $user;

    // test the talk method
    protected function setUp() {
        $this->user = new User();
        $this->user->setName("Tom");
    }

    protected function tearDown() {
        unset($this->user);
    }

 public function testTalk() {
        $expected = "Hello world!";
        $actual = $this->user->talk();
        $this->assertEquals($expected, $actual);
    }

}

このクラスの場合:

<?php
class User {
    protected $name;

    public function getName() {
        return $this->name;
    }

    public function setName($name) {
        $this->name = $name;
    }

    public function talk() {
        return "Hello world!";
    }
}

わかりましたので、テストはテストの同等性に基づいて OK/Fail ステートメントを返すことを確立しましたが、私が探しているのはそれ以上です。この例とは異なり、その結果が簡単に推測できない、より複雑なクラスを実際にテストする方法が必要です。

たとえば、ポーリングを行うスクリプトを作成します。メソッド/クラスが機能するかどうか、またはどのようにテストできますか? 上記のコードは、メソッドの結果が次のようになるかどうかのみを示しています。'Hello World'ただし、複雑なことをテストする必要があり、そのためのチュートリアルがあまりないため、テストするには簡単すぎます。

4

2 に答える 2

7

単体テストでのクラスのテストは複雑ではないはずです。

これが当てはまる理由は、適切に設計されたシステムでは、そのクラスを分離してテストでき、そのクラスの背後にあるシステムの複雑さを追加しないためです-そのシステムはテスト中に存在しないため、モックされます.

これの古典的な例は、通常 User クラスがデータベースに情報を要求することですが、テスト ケースでは、そのデータベースをセットアップし、データを準備し、後で破棄するのは非常に困難です。また、実際のデータベースを使用すると速度が低下します。そのため、外部からデータベース オブジェクトを受け入れるように User クラスを設計し、テスト ケースではそれにデータベースのモック オブジェクトを渡します。

そうすれば、データベースからのあらゆる種類の戻り値をシミュレートするのは非常に簡単です。さらに、実際のデータベースを扱う複雑さなしに、データベース オブジェクトが正しいパラメーターを取得するかどうかを確認できます。

クラスが依存性注入を許可するように設計されている場合にのみ、適切なモック オブジェクト インジェクションを行うことができます。これは、他のオブジェクトの内部にオブジェクトを作成しないという原則ですが、それらを提供するために外の世界を必要とします。説明のためにいくつかのビデオを簡単に見てください。

また、優れたテストを作成するにはある程度の経験が必要であることを忘れないでください。実験を始めてよかったです。

于 2013-08-10T18:59:29.523 に答える
4

しかし、複雑なことをテストする必要があり、そのためのチュートリアルがあまりないため、テストするのは簡単すぎます。

複雑になればなるほど、テストは複雑になります。それは自分自身の最後を噛むヘビのようなものです。通常はそれを防ぎたいので、それをゴールデンにするには: 単純なテストを記述して、複雑なソフトウェアがテストされ、実行されることを確認します。

これは常に 100% 機能するとは限りませんが、テストを行わないよりはうまく機能します。PHPUnit は単体テスト ( Xunit テスト パターン) 用に設計されていますが、それを使用してさまざまなテストを実行することもできます。そのために、テストをグループ化します。これは、さまざまなことに応じて、さまざまな人によってさまざまに行われます。例えば：

  1. 小さなテスト
  2. 中程度のテスト
  3. 大規模なテスト

または (同等ではない):

  1. 単体テスト
  2. 統合テスト
  3. 受け入れテスト

または (おそらく同等の TestPyramid ):

  1. 単体テスト
  2. サービステスト
  3. UI テスト

そして、そうではありません。テストを開始するときは、単体テストから開始することをお勧めします。Sven が既に回答しているように、それらは単純にしておいてください。TDD に慣れ、スライドや本を読んでください。テストの自動化の世界へようこそ。

PS はい、単純なゲッター セッターはテストが簡単すぎます。セッターがプライベート メンバーに格納するだけで、ゲッターがそれを取得する場合、PHP が動作していると信頼できます。そのためのテストを作成するのは時間の無駄であり、クラフトにつながるだけです。コードが書かれた後に誰かがテストを書いたことを明確に示しています。代わりに、最初にテストを書き、それが失敗することを確認します (赤)。できるだけ早くコードをハックしてテストに合格する (緑)。テストで既に機能していることを示しているため、後でコードを改善できます。

于 2013-08-12T05:39:56.277 に答える