php单元测试进阶（10）- 核心技术 - 桩件(stub) - 调用方法注入桩件
本系列文章主要代码与文字来源于《单元测试的艺术》，原作者：Roy Osherove。译者：金迎。
本系列文章根据php的语法与使用习惯做了改编。所有代码在本机测试通过。如转载请注明出处。
使用本方法的步骤如下。
在被测试类中：
- 添加一个返回真实实例的方法
- 正常的在代码中使用该方法
在测试代码中：
- 创建一个新类继承被测类
- 创建一个你要替换的接口的那个类型的公共字段
- 重写被测类的返回真实实例的方法
- 返回上面的公共字段
在测试类中：
- 创建一个桩件，此桩件实现了要替换的接口
- 创建新派生类而非被测类的实例
- 配置这个新的实例，注入桩件
与前文比较，上文介绍了工厂类注入桩件，源代码4个文件，测试代码2个文件。
本文介绍调用方法注入桩件，源代码3个文件，测试代码3个文件。
一个接口和两个实现不变，被测类改变，测试类改变，新加一个测试辅助类即派生类。
本方法的要点：其实测试的是子类，而不是原本的被测类。
这种方法比前面几个好，因为它使你无需进入更深层次（改变调用栈深处的依赖）即可直接替换依赖项，实现起来干净快速。
这种方法的缺点：非常适合用来模拟提供给被测代码的输入，但是如果用来验证从被测代码到依赖项的调用却十分不便。
例如，如果测试代码调用一个web服务，得到一个返回值，你想要模拟自己的返回值，使用这个方法很好。但是如果你想测试代码对web服务的调用是否正确，事情很快就变糟了。这需要大量的手工编码，而mock框架或类库更适合做这样的工作。总之，本方法适合模拟返回值或者整个返回接口，但不适合检查对象之间的交互。
源代码
（1）t2\application\index\controller下根据测试需要（实际是解耦，让程序更加结构清晰）提取的接口
IExtensionManager.php（未改动）
<?php
namespace app\index\controller;
/**
* 文件名是否有效接口
* 源代码中的文件管理器类会实现，一个桩件也会实现
* 接口的存在，让所有代码的含义更加清晰，稳定。
*/
interface IExtensionManager
{
/**
* 判断文件名是否有效
* @param string $filename
* @return boolean
*/
public function isValid($filename);
}
（2）t2\application\index\controller下文件管理器类，实现了上面的接口，但是实际被排除在单元测试之外，不测它。应该使用集成测试来测试此类。
FileExtensionManager.php（未改动）
<?php
namespace app\index\controller;
/**
* 文件管理器类
*
*/
class FileExtensionManager implements IExtensionManager
{
/**
* 根据某个配置文件的内容判断文件名是否有效
* @param string $filename
*/
public function isValid($filename)
{
// 会使用file_get_contents函数读取某个文件的内容
// 这里为了简略不写，因为不是重点。
return true;
}
}
（3）t2\application\index\controller下被测类，日志分析器。使用了调用方法注入的方式来写代码，便于派生类覆盖，然后测试
LogAnalyzer.php
<?php
namespace app\index\controller;
/**
* 日志分析器类，也是被测类
*
* 注意，这是用调用方法注入桩件的例子。
*/
class LogAnalyzer
{
/**
* 判断文件名是否有效，调用另一个类来实现
* @param string $filename
*/
public function isValidLogFileName($filename)
{
return $this->getManager()->isValid($filename);
}
protected function getManager()
{
return new FileExtensionManager();
}
}
测试代码
（4）t2\tests\index\controller\下，桩件类，用于替换文件管理器，便于测试
FakeExtensionManager.php（未改动）
<?php
namespace tests\index\controller;
/**
* 一个桩件类，用于测试日志分析器，因为日志分析会读取文件，妨碍单元测试。
*/
class FakeExtensionManager implements \app\index\controller\IExtensionManager
{
public $willBeValid = false;
/**
* 根据某个配置文件的内容判断文件名是否有效
* @param string $filename
*/
public function isValid($filename)
{
return $this->willBeValid;
}
}
（5）t2\tests\index\controller\下，被测试类的子类，用于覆盖产生桩件的方法，便于测试。因为这个子类测试专用，所以当然放在测试文件夹下。
LogAnalyzerExtend.php
<?php
namespace tests\index\controller;
use app\index\controller\IExtensionManager;
/**
* 测试辅助类，是源代码被测类的子类。用于覆盖原被测类的方法，便于测试。
* 请注意本类写法，为了代码更加通用，使用了构造方法注入桩件，而不是写死。
* 其实也可以写死，代码更少，只是此类就不能复用了。
*
* 但是又可以看到，万一原代码有构造方法呢，冲突咋办？其实没关系。
* 因为我们可以为了测试源代码的一个类的多个方法，写不同的测试辅助类来对应。
*/
class LogAnalyzerExtend extends \app\index\controller\LogAnalyzer
{
/**
* @var \app\index\controller\IExtensionManager
*/
private $manager;
/**
* 用构造方法注入
* @param \app\index\controller\IExtensionManager $mgr
*/
public function __construct($mgr)
{
$this->manager = $mgr;
}
/**
* 覆盖原方法，便于测试
*/
protected function getManager()
{
return $this->manager;
}
}
（6）t2\tests\index\controller\下，最后是测试类，但不是测试被测试类，而是测试被测试类的子类。
LogAnalyzerTest.php
<?php
namespace tests\index\controller;
/**
* 测试用的类
*/
class LogAnalyzerTest extends \think\testing\TestCase
{
/**
* @test
* 使用静态工厂注入桩件的方法 进行测试
* 注意，尽量使得测试的方法名称有意义，这非常重要，便于维护测试代码。有规律
*/
public function isValidFileName_NameSupportedExtension_ReturnTrue()
{
//准备好一个返回true的桩件。
$myFakeManager = new FakeExtensionManager();
$myFakeManager->willBeValid = true;
//开始创建被测类的子类的对象，注入桩件，准备测试
$analyzer = new LogAnalyzerExtend($myFakeManager); //创建同时注入
$result = $analyzer->isValidLogFileName("short.ext");
$this->assertTrue($result);
}
}
cmd下测试通过。
上一篇：php单元测试进阶（9）- 核心技术 - 桩件(stub) - 工厂类注入桩件
下一篇：php单元测试进阶（11）- 核心技术 - 桩件(stub) - 不使用桩件
