Thực tiễn tốt nhất để kiểm tra các phương thức được bảo vệ bằng PHPUnit

Tôi tìm thấy các cuộc thảo luận về Bạn có kiểm tra thông tin phương pháp riêng tư .

Tôi đã quyết định, trong một số lớp, tôi muốn có các phương thức được bảo vệ, nhưng kiểm tra chúng. Một số phương pháp này là tĩnh và ngắn. Bởi vì hầu hết các phương pháp công khai sử dụng chúng, tôi có thể sẽ có thể loại bỏ các bài kiểm tra một cách an toàn sau này. Nhưng để bắt đầu với cách tiếp cận TDD và tránh gỡ lỗi, tôi thực sự muốn thử nghiệm chúng.

Tôi nghĩ về những điều sau đây:

• Phương pháp Đối tượng như được khuyên trong một câu trả lời dường như là quá mức cần thiết cho việc này.
• Bắt đầu với các phương thức công khai và khi phạm vi bảo hiểm được đưa ra bởi các thử nghiệm cấp cao hơn, hãy chuyển chúng được bảo vệ và loại bỏ các thử nghiệm.
• Kế thừa một lớp với giao diện có thể kiểm tra làm cho các phương thức được bảo vệ trở nên công khai

Đó là thực hành tốt nhất? Có gì khác?

Dường như, JUnit tự động thay đổi các phương thức được bảo vệ thành công khai, nhưng tôi không có cái nhìn sâu hơn về nó. PHP không cho phép điều này thông qua sự phản ánh .

Nếu bạn đang sử dụng PHP5 (> = 5.3.2) với PHPUnit, bạn có thể kiểm tra các phương thức riêng tư và được bảo vệ của mình bằng cách sử dụng sự phản chiếu để đặt chúng ở chế độ công khai trước khi chạy thử nghiệm của bạn:

protected static function getMethod($name) {
  $class = new ReflectionClass('MyClass');
  $method = $class->getMethod($name);
  $method->setAccessible(true);
  return $method;
}

public function testFoo() {
  $foo = self::getMethod('foo');
  $obj = new MyClass();
  $foo->invokeArgs($obj, array(...));
  ...
}

Bạn dường như đã nhận thức được, nhưng dù sao tôi cũng sẽ nói lại; Đó là một dấu hiệu xấu, nếu bạn cần thử nghiệm các phương pháp được bảo vệ. Mục đích của một bài kiểm tra đơn vị, là để kiểm tra giao diện của một lớp và các phương thức được bảo vệ là các chi tiết triển khai. Điều đó nói rằng, có những trường hợp nó có ý nghĩa. Nếu bạn sử dụng tính kế thừa, bạn có thể thấy một siêu lớp khi cung cấp giao diện cho lớp con. Vì vậy, ở đây, bạn sẽ phải kiểm tra phương thức được bảo vệ (Nhưng không bao giờ là phương thức riêng tư ). Giải pháp cho vấn đề này là tạo ra một lớp con cho mục đích thử nghiệm và sử dụng phương thức này để trưng ra các phương thức. Ví dụ.:

class Foo {
  protected function stuff() {
    // secret stuff, you want to test
  }
}

class SubFoo extends Foo {
  public function exposedStuff() {
    return $this->stuff();
  }
}

Lưu ý rằng bạn luôn có thể thay thế sự kế thừa bằng thành phần. Khi kiểm tra mã, việc xử lý mã sử dụng mẫu này thường dễ dàng hơn rất nhiều, vì vậy bạn có thể muốn xem xét tùy chọn đó.

teastburn có cách tiếp cận đúng. Thậm chí đơn giản hơn là gọi phương thức trực tiếp và trả lời câu trả lời:

class PHPUnitUtil
{
  public static function callMethod($obj, $name, array $args) {
        $class = new \ReflectionClass($obj);
        $method = $class->getMethod($name);
        $method->setAccessible(true);
        return $method->invokeArgs($obj, $args);
    }
}

Bạn có thể gọi điều này đơn giản trong các thử nghiệm của bạn bằng cách:

$returnVal = PHPUnitUtil::callMethod(
                $this->object,
                '_nameOfProtectedMethod', 
                array($arg1, $arg2)
             );

Tôi muốn đề xuất một biến thể nhỏ cho getMethod () được xác định trong câu trả lời của uckelman .

Phiên bản này thay đổi getMethod () bằng cách xóa các giá trị được mã hóa cứng và đơn giản hóa việc sử dụng một chút. Tôi khuyên bạn nên thêm nó vào lớp PHPUnitUtil của bạn như trong ví dụ bên dưới hoặc vào lớp mở rộng PHPUnit_Framework_TestCase của bạn (hoặc, tôi cho rằng, trên toàn cầu vào tệp PHPUnitUtil của bạn).

Vì MyClass đang được khởi tạo bằng mọi cách và ReflectionClass có thể lấy một chuỗi hoặc một đối tượng ...

class PHPUnitUtil {
    /**
     * Get a private or protected method for testing/documentation purposes.
     * How to use for MyClass->foo():
     *      $cls = new MyClass();
     *      $foo = PHPUnitUtil::getPrivateMethod($cls, 'foo');
     *      $foo->invoke($cls, $...);
     * @param object $obj The instantiated instance of your class
     * @param string $name The name of your private/protected method
     * @return ReflectionMethod The method you asked for
     */
    public static function getPrivateMethod($obj, $name) {
      $class = new ReflectionClass($obj);
      $method = $class->getMethod($name);
      $method->setAccessible(true);
      return $method;
    }
    // ... some other functions
}

Tôi cũng đã tạo một hàm bí danh getProtectedMethod () để rõ ràng những gì được mong đợi, nhưng đó là tùy thuộc vào bạn.

Chúc mừng!

Tôi nghĩ troelskn là gần. Tôi sẽ làm điều này thay vào đó:

class ClassToTest
{
   protected function testThisMethod()
   {
     // Implement stuff here
   }
}

Sau đó, thực hiện một cái gì đó như thế này:

class TestClassToTest extends ClassToTest
{
  public function testThisMethod()
  {
    return parent::testThisMethod();
  }
}

Sau đó, bạn chạy thử nghiệm của mình chống lại TestClassToTest.

Có thể tự động tạo các lớp mở rộng như vậy bằng cách phân tích mã. Tôi sẽ không ngạc nhiên nếu PHPUnit đã cung cấp một cơ chế như vậy (mặc dù tôi chưa kiểm tra).

Tôi sẽ ném mũ vào vòng ở đây:

Tôi đã sử dụng hack __call với nhiều mức độ thành công khác nhau. Cách khác tôi nghĩ ra là sử dụng mẫu Khách truy cập:

1: tạo lớp stdClass hoặc lớp tùy chỉnh (để thực thi kiểu)

2: nguyên tố với phương thức và đối số cần thiết

3: đảm bảo rằng SUT của bạn có phương thức acceptVisitor sẽ thực thi phương thức với các đối số được chỉ định trong lớp truy cập

4: tiêm nó vào lớp bạn muốn kiểm tra

5: SUT tiêm kết quả hoạt động vào khách truy cập

6: áp dụng điều kiện kiểm tra của bạn cho thuộc tính kết quả của Khách truy cập

Bạn thực sự có thể sử dụng __call () theo cách chung để truy cập các phương thức được bảo vệ. Để có thể kiểm tra lớp này

class Example {
    protected function getMessage() {
        return 'hello';
    }
}

bạn tạo một lớp con trong exampleTest.php:

class ExampleExposed extends Example {
    public function __call($method, array $args = array()) {
        if (!method_exists($this, $method))
            throw new BadMethodCallException("method '$method' does not exist");
        return call_user_func_array(array($this, $method), $args);
    }
}

Lưu ý rằng phương thức __call () không tham chiếu lớp theo bất kỳ cách nào để bạn có thể sao chép phần trên cho mỗi lớp bằng các phương thức được bảo vệ mà bạn muốn kiểm tra và chỉ cần thay đổi khai báo lớp. Bạn có thể đặt chức năng này trong một lớp cơ sở chung, nhưng tôi chưa thử.

Bây giờ, trường hợp thử nghiệm chỉ khác ở chỗ bạn xây dựng đối tượng cần kiểm tra, hoán đổi trong Ví dụExposed cho ví dụ.

class ExampleTest extends PHPUnit_Framework_TestCase {
    function testGetMessage() {
        $fixture = new ExampleExposed();
        self::assertEquals('hello', $fixture->getMessage());
    }
}

Tôi tin rằng PHP 5.3 cho phép bạn sử dụng sự phản chiếu để thay đổi khả năng truy cập trực tiếp của các phương thức, nhưng tôi cho rằng bạn phải làm như vậy cho từng phương thức riêng lẻ.

Tôi đề nghị cách giải quyết sau cho cách giải quyết / ý tưởng của "Henrik Paul" :)

Bạn biết tên của các phương thức riêng tư của lớp bạn. Ví dụ: chúng giống như _add (), _edit (), _delete (), v.v.

Do đó, khi bạn muốn kiểm tra nó từ khía cạnh của kiểm thử đơn vị, chỉ cần gọi các phương thức riêng tư bằng cách thêm tiền tố và / hoặc thêm một số từ phổ biến (ví dụ _addPhastait) để khi phương thức __call () được gọi (vì phương thức _addPhastait () không tồn tại) của lớp chủ sở hữu, bạn chỉ cần đặt mã cần thiết vào phương thức __call () để loại bỏ từ / s có hậu tố (Phastait) và sau đó gọi phương thức riêng được suy ra từ đó. Đây là một cách sử dụng tốt các phương pháp ma thuật.

Hãy thử nó.