我前面的文章有介绍过，桩有三个功能：隔离、补齐，控制。其中，控制功能就是用于解决内部输入的，因此，打桩并手工修改桩代码，是解决内部输入的方法之一。
关于编写桩的方法，已在第4章介绍过，这里不再重复。关于如何让桩与用例匹配，请阅读第9章。
遗憾的是，编写桩代码不但增加工作量，而且不能解决所有的内部输入，下面对内部输入分类分析：
自然输入：自然输入调用实际代码，不需要特别解决，跟桩无关。
不可控：不可控调用的也是实际代码，并不调用桩代码，因此也不能解决。另外编写桩代码来代替实际代码行不行？在应该调用实际代码的时候，要想调用桩代码可能很麻烦，例如，底层函数位于同一个文件，或同一个类，通常要用编译条件来区分实际代码和桩代码，不但麻烦，而且污染产品代码。
难于初始化：也是调用实际代码。
静态输入：静态输入只涉及到局部静态变量，没有调用底层函数，当然也不能用桩来代替。
中断输入：中断输入是在不确定位置，中断调用不确定的代码形成的，也不能用桩来代替。
失真：失真是打桩造成的，调用的是桩代码。在比较简单的情形下，可以用命名法来控制桩代码的输出，即给每个用例命名，桩代码中判断用例名来决定输出，具体方法在前文已经介绍过。如果在同一个用例中，多次调用同一个桩，每次要求输出不同，命名法就无效了。这种情形是很常见的，例如一个函数多次调用同一个底层函数，或在循环中调用桩代码。一个被测函数可能调用多个桩，一个桩又可能被多个被测函数调用，这种多对多的关系下，很难维护用例与桩的对应。用例可能很多，还可能要不断增加和修改，维护用例与桩输出的关系也很麻烦。
总之，在实际的应用中，在测试的时间成本受限的情形下，编写桩代码一般只能解决部分失真，难以适应复杂的应用。
