對於PHPUnit測試私人屬性和方法的功能分析

這篇文章主要介紹了PHPUnit測試私人屬性和方法功能,結合執行個體形式較為詳細的分析了使用PHPUnit針對私人屬性和方法進行測試的相關操作技巧與注意事項,需要的朋友可以參考下

本文執行個體講述了PHPUnit測試私人屬性和方法功能。分享給大家供大家參考，具體如下：

一、測試類別中的私人方法：

class Sample{  private $a = 0;  private function run()  {    echo $a;  }}

上面只是簡單的寫了一個類包含，一個私人變數和一個私人方法。對於protected和private方法，由於無法像是用public方法一樣直接調用，所以在使用phpunit進行單測的時候，多有不便，特別是當一個類中，對外只提供少量介面，內部使用了大量private方法的情況。

對於protected方法，建議使用繼承的方式進行測試，在此就不再贅述。而對於private方法的測試，建議使用php的反射機制來進行。話不多說，上代碼：

class testSample(){    $method = new ReflectionMethod('Sample', 'run');    $method->setAccessible(true); //將run方法從private變成類似於public的許可權    $method->invoke(new Sample()); //調用run方法}

如果run方法是靜態，如：

private static function run(){  echo 'run is a private static function';}

那麼invoke函數還可以這麼寫：

$method->invoke(null); //只有靜態方法可以不必傳類的執行個體化

如果run還需要傳參，比如：

private function run($x, $y){  return $x + $y;}

那麼，測試代碼可以改為：

$method->invokeArgs(new Sample(), array(1, 2));//array中依次寫入要傳的參數。執行結果返回3

【注意】：利用反射的方法測試私人方法雖好，但setAccessible函數是php5.3.2版本以後才支援的（>=5.3.2）

二、私人屬性的get/set

說完了私人方法，再來看看私人屬性，依舊拿Sample類作為例子，想要擷取或設定Sample類中的私人屬性$a的值可以用如下方法：

public function testPrivateProperty(){  $reflectedClass = new ReflectionClass('Sample');  $reflectedProperty = $reflectedClass->getProperty('a');  $reflectedProperty->setAccessible(true);  $reflectedProperty->getValue(); //擷取$a的值  $reflectedProperty->setValue(123); //給$a賦值:$a = 123;}

上述方法對靜態屬性依然有效。

到此，是不是瞬間感覺測試私人方法或屬性變得很容易了。

附：PHPunit 測試私人方法（英文原文）

This article is part of a series on testing untestable code:

• Testing private methods

• Testing code that uses singletons

• Stubbing static methods

• Stubbing hard-coded dependencies

No, not those privates. If you need help with those, this book might help.

One question I get over and over again when talking about Unit Testing is this:

"How do I test the private attributes and methods of my objects?"

Lets assume we have a class Foo:

<?phpclass Foo{  private $bar = 'baz';  public function doSomething()  {    return $this->bar = $this->doSomethingPrivate();  }  private function doSomethingPrivate()  {    return 'blah';  }}?>

Before we explore how protected and private attributes and methods can be tested directly, lets have a look at how they can be tested indirectly.

The following test calls the testDoSomething() method which in turn calls thedoSomethingPrivate() method:

<?phpclass FooTest extends PHPUnit_Framework_TestCase{  /**   * @covers Foo::doSomething   * @covers Foo::doSomethingPrivate   */  public function testDoSomething()  {    $foo = new Foo;    $this->assertEquals('blah', $foo->doSomething());  }}?>

The test above assumes that testDoSomething() only works correctly whentestDoSomethingPrivate() works correctly. This means that we have indirectly testedtestDoSomethingPrivate(). The problem with this approach is that when the test fails we do not know directly where the root cause for the failure is. It could be in eithertestDoSomething() or testDoSomethingPrivate(). This makes the test less valuable.

PHPUnit supports reading protected and private attributes through thePHPUnit_Framework_Assert::readAttribute() method. Convenience wrappers such asPHPUnit_Framework_TestCase::assertAttributeEquals() exist to express assertions onprotected and private attributes:

<?phpclass FooTest extends PHPUnit_Framework_TestCase{  public function testPrivateAttribute()  {    $this->assertAttributeEquals(     'baz', /* expected value */     'bar', /* attribute name */     new Foo /* object     */    );  }}?>

PHP 5.3.2 introduces the ReflectionMethod::setAccessible() method to allow the invocation of protected and private methods through the Reflection API:

<?phpclass FooTest extends PHPUnit_Framework_TestCase{  /**   * @covers Foo::doSomethingPrivate   */  public function testPrivateMethod()  {    $method = new ReflectionMethod(     'Foo', 'doSomethingPrivate'    );    $method->setAccessible(TRUE);    $this->assertEquals(     'blah', $method->invoke(new Foo)    );  }}?>

In the test above we directly test testDoSomethingPrivate(). When it fails we immediately know where to look for the root cause.

I agree with Dave Thomas and Andy Hunt, who write in their book "Pragmatic Unit Testing":

"In general, you don't want to break any encapsulation for the sake of testing (or as Mom used to say, "don't expose your privates!"). Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there's another class in there struggling to get out."

So: Just because the testing of protected and private attributes and methods is possible does not mean that this is a "good thing".

以上就是本文的全部內容，希望對大家的學習有所協助，更多相關內容請關注topic.alibabacloud.com！