当你遇到以上这些令你沮丧的情况时，你一定会想能有什么更好的办法去解决呢?办法当然是有的!这就是使用单元测试。单元测试不但可以在一定程度上解决上述头疼的问题，而且能让代码变的容易维护，还可以能让你更多地对代码进行重构。
一旦你编写好单元测试用例，当你需要修改你的代码时，你要做的事情就是重新运行你的单元测试用例并观察这些单元测试用例能否通过，如果通过了的话，证明代码是没问题的。
人们往往会说：既然单元测试这么好，为什么那么多人还是不大愿意去写单元测试呢?有以下几种理解上的误曲：
1、认为编写单元测试太浪费时间。虽然目前很多IDE工具都为编写单元测试建立好了框架，但还是要开发者编写一些单元测试的代码的。就象很多开发中的最佳实践一样，用正确的方法去做正确的事情会为开发节省大量的时间。每当新增加新功能时，你可能通过访问你的网页到处去点击手动测试，而运行建立好的单元测试用例其速度其实比通过手工去测试的速度更快。
2、认为既然代码能运行了，不需要再编写单元测试。但假设团队中有新的成员，如果没有良好的单元测试用例，新成员很有可能随意地去编码而不考虑各种后果。如果有编写良好的单元测试，在程序运行时进行各种测试，则能最大程度避免bug的产生。
3、认为编写单元测试代码枯燥无味。程序员的天性是解决问题，而很多程序员认为在紧张的编码工作时，还要编写单元测试代码，会很枯燥。但要知道的是，如果能通过编写单元测试在很早的阶段就能尽可能发现代码中多的错误的话，那么既节省时间减少了出错，何乐而不为?
开始动手安装phpunit
本文中将通过介绍php中的单元测试利器phpunit(),并通过实际例子来讲解如何在实际工作中运用phpunit。首先安装phpunit的方法可以通过php下的pear去安装：
如果你想通过手动方式去安装，可以参考phpunit的手册去安装()。
编写第一个单元测试用例
下面我们开始编写第一个单元测试用例。在编写测试用例时，要遵守如下的phpunit的规则：
1 一般地，在测试用例中，可以扩展PHPUnit_Framework_TestCase类，这样就可以使用象setUp(),tearDown()等方法了。
2 测试用例的名字最好是使用约定俗成的格式，即在被测试类的后面加上”Test”,比如要测试的类为RemoteConnect,则测试用例的命名为RemoteConnectTest。
3 在一个测试用例中的所有的测试方法，在命名时都应该以test+测试方法名去命名，如testDoesLikeWaffles(),要注意的是该方法必须是声明为public类型的。当然可以在你的测试用例中包含private的方法，但它们不能被phpunit所调用。
4 测试方法中是不能接收参数的。
下面首先举个简单的例子，代码如下：
上面的代码其实是实现连接到一个指定的服务器的功能，那么我们可以编写测试代码如下：