可以看到其实这是在实现代码中添加了一个条件判断分支，我们也许需要为条件分支再单独写一个单元测试（略）。
第三种情况，即需求发生重大变化，导致代码结构发生严重变化，那么基本之前的所有单元测试和实现代码都已经作废，甚至编译无法通过。
四、对某个方法内的实现进行优化
其实单元测试在开发完成后能起到的作用，仅限于这种场景，对一个方法的实现进行优化，例如VanclProvider类的QueryPriceByProductID方法由以前从数据库查询，改为先从本地缓存中读取，若缓存不存在才从数据库中读取，因为期望值并为发生改变，只是修改了这个方法的实现方式，因此在修改之后依然可以通过单元测试进行验收是否修改正确，即新的修改是否依然符合早期的需求（期望值没发生改变，则单元测试不发生改变）。
误区：
很多朋友一直把单元测试和集成测试搞混，因此一直有个误区：
认为只要对所有方法都编写了单元测试，在将来代码发生变化之后，可以通过运行单元测试快速的通过计算机校验得到所有受当前代码变化影响的用例以及影响范围。实际上，如果你仔细看到这里，你应该已经知道，这其实是不可能的。
单元测试的隔离性，导致了代码的影响不会传递：一个方法的实现导致了异常，并不会影响到其他调用过它的方法在原有的单元测试中顺利通过（Mock方法代替了实际方法的执行）。
总结：
通过以上这些例子，描述了如何结合测试先行的思想去做单元测试，核心的一点即是：目标先行，每实现一个方法之前先考虑这个方法要达到的目标是什么，再编写这个目标的检测手段（单元测试），最终去实现这个方法，并通过之前设想和编写的检测手段去验证这个实现是否已经达到预期的目标。
另一方面，这个过程也强烈的反应出了，单元测试作为测试的一种手段，其实在代码实现后，即维护阶段能起到的作用非常的小：
当需求发生变化时，需求的预期值必然发生变化，意味着单元测试需要被修改或重新编写。此时，原有的单元测试已经起不到事后检查的作用了。
只有在需求未发生改变时，对现有代码进行不涉及结构改变的优化时，用于修改后的代码是否依然满足之前的需求预期。但实际应用中，这种场景少之又少。
相关链接：
