测试实现

有了领域模型，大家自然会想着如何去实现业务应用了，而实现应用的过程中一定会考虑到单元测试的设计。在构建高质量软件过程中，单元测试已经成为了标准规范，但高质量的单元测试却是困扰很多团队的普遍问题。很多时候设计测试比实现应用本身更加困难。

这里很难有一个固定标准来评判某个时间点的单元测试质量，但一个核心的原则是让用例尽量测试业务需求而不是实现方式本身。满足业务需求是我们的目标，实现方式可能有多种，我们不希望需要持续重构的实现代码影响到我们的测试用例。比如针对实现过程中的某个函数进行入参和出参的单元测试，当这个函数发生一点改变（即使是重命名），我们也需要改动测试。

测试驱动开发TDD无疑是一种好的实践，如果应用得当，它确实能够实现我们上述的原则，并且能够帮助我们交流业务的需求。比较有意思的是，在基于DDD建立的核心模型之上应用TDD似乎更加顺理成章。类比DDD和TDD虽然是不恰当的，但我们会发现两者在遵循的原则上是一致的，即都是面向业务做分解和设计：DDD就整个业务问题域进行了分解，形成子问题域；TDD就业务需求在实现时进行任务分解，从简单场景到复杂场景逐步通过测试驱动出实现。下面的测试用例展现了在核心模型上的TDD过程。

上面测试了收到一条创建信息后实例化一个Cargo的简单场景，要求创建后的Cargo的标识id跟信息里的一致，并且出货的日期一致。这个测试驱动出来一个Interface的Api::CreateCargo。

下面是另外一个测试推迟delay的场景，同样我们看到了驱动出的Api::Delay的实现。

长期以来对于TDD这个实践大家都有架构设计上的疑惑，很多资深架构师担心完全从业务需求驱动出实现没法形成有效的技术架构，而且每次实现的重构成本都可能很高。DDD的引入从某种程度上解决了这个顾虑，通过前期的战略和战术建模确定了核心领域架构，这个架构是通过预先综合讨论决策的，考虑了更广阔的业务问题，较之TDD应用的业务需求层面更加宏观。在已有核心模型基础上我们也会发现测试用例的设计更容易从应用视角出发，从而降低了测试设计的难度。