本系列文章主要代码与文字来源于《单元测试的艺术》，原作者：Roy Osherove。译者：金迎。
本系列文章根据php的语法与使用习惯做了改编。所有代码在本机测试通过。如转载请注明出处。
一个桩件(stub)是对系统中存在的一个依赖项（或者协作者）的可控制的替代物。通过使用桩件，你在测试代码时无需直接处理这个依赖项。
让我们把前面的LogAnalyzer日志分析类实现得更加复杂。
LogAnalyzer类的应用程序可以配置成处理多个日志文件扩展名，每种文件使用一个特殊的适配器。为简单起见，我们可以假设程序支持的各种文件名作为应用程序的配置文件存放在磁盘的某个地方，方法如下
public function isValidLogFileName($filename)
{
// 读取某个配置文件，根据文件内容决定$filename是否合法。
// ... ...
// php经常使用file_get_contents这个函数读取文件内容。。
}
因为被测方法依赖了文件系统，而单元测试不应该与文件系统打交道（好处是极快，且代码通用，无环境依赖）
如何使测试LogAnalyzer类变的容易：抽取接口使底层实现可替换
需要增加一个间接层FileExtensionManager，现在，t2\application\index\controller下有两个文件。
文件管理器类FileExtensionManager.php如下：
<?php
namespace app\index\controller;
/**
* 文件管理器类
*
*/
class FileExtensionManager
{
/**
* 根据某个配置文件的内容判断文件名是否有效
* @param string $filename
*/
public function isValid($filename)
{
// 会使用file_get_contents函数读取某个文件的内容
// 这里为了简略不写，因为不是重点。
return true;
}
}
和被测类日志分析器类LogAnalyzer.php，代码如下
<?php
namespace app\index\controller;
/**
* 日志分析器类，也是被测类
*
*/
class LogAnalyzer
{
/**
* 判断文件名是否有效，调用另一个类来实现
* @param string $filename
*/
public function isValidLogFileName($filename)
{
$mgr = new FileExtensionManager();
return $mgr->isValid($filename);
}
}
然而这么做还是远远不够的。
源代码现在有两个类，
（1）源代码还需增加一个isValid()接口，
（2）源代码让文件管理器类实现此接口
（3）测试代码得增加一个桩件实现接口
（4）日志分析器类得允许注入，无论是文件管理器类或是桩件，不能写死。以便于测试。
文章太长了，下一篇给出全部代码
额外说明，关于FileExtensionManager类的正确性，由集成测试保证，本系列文章只关注单元测试。
上一篇： php单元测试进阶（5）- 入门 - 异常测试
下一篇： php单元测试进阶（7）- 核心技术 - 桩件(stub) - 构造函数注入桩件