《测试驱动开发与设计模式中的测试挑战及解决方案》
1. 测试性与设计模式带来的挑战
可测试性是衡量代码质量的重要线索，但使用设计模式有时却会引发测试问题。如果设计模式反映的特性正是测试期望引导我们达成的，为何使用模式反而让测试变得更难了呢？
就像一个著名的故事，一位科学家在天文学讲座上讲述地球绕太阳转，太阳绕银河系中心转，然而一位老妇人却称世界是平的，由一只巨龟驮着。当科学家问巨龟站在什么上面时，老妇人说“层层都是龟”。
好的面向对象设计有时也类似，存在大量委托和复杂的情况。从维护角度看，这种设计能带来更多封装、更强内聚等好处，但从测试角度，这些好处是以增加复杂性为代价的，这显然不利于测试。
那么，设计模式和测试驱动开发（TDD）哪个是对的呢？答案是两者都对。比如，我们可能需要将上下文对象（Context）和策略实现分开测试，并且认为上下文对象不应包含特定策略实现的知识，其测试应与策略细节解耦。
2. 策略模式中的测试问题及解决方案
2.1 策略模式测试问题
重新审视策略模式示例，为其添加了四个类：
- Strategy_V1_Test
- Strategy_V2_Test
- Context_Test
- Mock
前两个类再次证明了测试在保持类内聚和解耦方面的价值。每个策略实现都是一个单独的算法，可独立测试上下文对象使用它们的特定方式。也就是说，每个策略实现的代码由其自身的测试覆盖，无需上下文对象的测试再去覆盖。
例如，上下文对象代表资产（Asset），策略代表两种不同的摊销算法：直线摊销法（Straight_
