如何借助TDD完成抽象系统设计的拆分？

TDD 的核心流程「红-绿-重构」本身就和架构的迭代演化完全适配，不需要提前把所有抽象层、设计模式都预设完毕再开始写代码，你可以按照以下路径推进：

第一步：从最小可用场景切入，先不考虑复杂封装 #

你完全可以从最开始想到的三参数兑换函数开始写测试，先写第一个最小粒度的测试用例，比如：

def test_usd_to_cny():
    assert currency_convert("USD", "CNY", 1) == 7.2

此时测试必然不通过，你只需要写最朴素的实现让测试变绿即可，甚至可以先硬编码返回结果，不需要考虑任何扩展性。
之后逐步增加更多测试用例：不同兑换币种、不同金额、边界值（比如0金额、负金额校验），每新增一个测试，就对应修改实现逻辑让测试通过，直到覆盖当前阶段所有已知的功能需求。

第二步：遇到痛点时再做重构，抽象层是重构出来的不是提前设计的 #

当你写了足够多的测试和基础实现后，自然会遇到用字符串表示货币的痛点：比如容易出现拼写错误、每次都要校验币种字符串合法性、不同币种的特殊逻辑（比如小数位精度限制）无法统一封装，这时候你再动手重构出Currency抽象类、Dollar/Yuan等子类替换原来的字符串参数即可。
重构过程中你之前写的所有测试就是安全保障，每改一部分就跑一遍测试，就能保证重构后的逻辑和原有功能完全一致，不会出现改崩的情况。

第三步：按需引入设计模式，不做过度设计 #

等到后续你遇到「需要动态生成不同币种实例」「新增币种时需要修改的代码位置太多」这类明确的痛点时，再对应引入工厂模式、抽象工厂等设计模式即可，不需要提前把这些模式硬套到还没出现对应需求的代码里。

你可以提前有大概的架构方向预判，但不要在需求还没浮现的时候就把所有抽象层都写死，TDD 产出的优秀架构都是跟着需求迭代逐步演化出来的，不是一开始就设计完美的。

内容的提问来源于stack exchange，提问作者Ruslan Chernenko