一旦你编写好单元测试用例，当你需要修改你的代码时，你要做的事情就是重新运行你的单元测试用例并观察这些单元测试用例能否通过，如果通过了的话，证明代码是没问题的。

　　人们往往会说：既然单元测试这么好，为什么那么多人还是不大愿意去写单元测试呢?有以下几种理解上的误曲：

　　1、认为编写单元测试太浪费时间。虽然目前很多IDE工具都为编写单元测试建立好了框架，但还是要开发者编写一些单元测试的代码的。就象很多开发中的最佳实践一样，用正确的方法去做正确的事情会为开发节省大量的时间。每当新增加新功能时，你可能通过访问你的网页到处去点击手动测试，而运行建立好的单元测试用例其速度其实比通过手工去测试的速度更快。

　　2、认为既然代码能运行了，不需要再编写单元测试。但假设团队中有新的成员，如果没有良好的单元测试用例，新成员很有可能随意地去编码而不考虑各种后果。如果有编写良好的单元测试，在程序运行时进行各种测试，则能最大程度避免bug的产生。

　　3、认为编写单元测试代码枯燥无味。程序员的天性是解决问题，而很多程序员认为在紧张的编码工作时，还要编写单元测试代码，会很枯燥。但要知道的是，如果能通过编写单元测试在很早的阶段就能尽可能发现代码中多的错误的话，那么既节省时间减少了出错，何乐而不为?

　　开始动手安装phpunit

　　本文中将通过介绍php中的单元测试利器phpunit(http://phpunit.de/),并通过实际例子来讲解如何在实际工作中运用phpunit。首先安装phpunit的方法可以通过php下的pear去安装：

de
　　pear channel

no
　　pear channel

com
    pear install phpunit

　　如果你想通过手动方式去安装，可以参考phpunit的手册去安装(http://www.phpunit.de/manual/3.0/en/installation.html)。

　　编写第一个单元测试用例

　　下面我们开始编写第一个单元测试用例。在编写测试用例时，要遵守如下的phpunit的规则：

　　1　一般地，在测试用例中，可以扩展phpUnit_Framework_TestCase类，这样就可以使用象setUp(),tearDown()等方法了。

　　2 测试用例的名字最好是使用约定俗成的格式，即在被测试类的后面加上”Test”,比如要测试的类为RemoteConnect,则测试用例的命名为RemoteConnectTest。

　　3 在一个测试用例中的所有的测试方法，在命名时都应该以test+测试方法名去命名，如testDoesLikeWaffles(),要注意的是该方法必须是声明为public类型的。当然可以在你的测试用例中包含private的方法，但它们不能被phpunit所调用。

　　4 测试方法中是不能接收参数的。

　　下面首先举个简单的例子，代码如下：

php

RemoteConnect
{
  

)
  {
    

){
      

s not a server name!”);
    }
    $fp = fsockopen($serverName,80);
    return ($fp) ? true : false;
  }
  public function returnSampleObject()
  {
    return $this;
  }
}
?>

 　　上面的代码其实是实现连接到一个指定的服务器的功能，那么我们可以编写测试代码如下：

php

);

phpUnit_Framework_TestCase
{
  

setUp(){ }
  

tearDown(){ }
  

testConnectionIsValid()
  {
    

RemoteConnect();
    

;
    

);
  }
}

 　　在上面的代码中，由于继承了phpUnit_Framework_TestCase类，因此在setUp和tearDown方法中，不需要编写任何代码。SetUp方法是在每个测试用例运行前进行一些初始化的工作，而tearDown则在每个测试用例运行后进行一些比如资源的释放等工作。在测试方法中，通过使用phpunit的断言assertTrue去判断所返回的布尔值是否为真，这里是通过调用RemoteConnect.php中的connectToServe方法去判断能否连接上服务器。

php技术：PHP单元测试利器 PHPUNIT初探第1/2页，转载需保留来源！

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。