TDD（ Test-Driven Development ）测试驱动研发
DDD（ Domain-DrivenDesign ）领域驱动模型
老板最近新接手一个新能源项目，对于代码的稳定性及CI/CD要求比较高，所以发现了TDD。由于我们之前代码的健壮性不是很理想，研发任务也不是很紧张，于是和我们组另外一个同学两个人就在之前项目的新模块中实践了一把。几年前项目中我使用过DDD，后来一直在项目中推行，由于种种原因实践效果并不理想，打算在这次实践中结合使用。
项目改造推进中遇到的困难有以下几点
1. 说服业务研发人员使用 TDD DDD
研发多了很多代码，周期大约增加了2-3倍，特别是对于之前没有写单元测试的习惯的程序员。对于初次接触TDD DDD的人来说，第一次也非常痛苦，我们现在的项目就是没有写业务单元测试的习惯，也没有接触TDD
2. TDD的 tasking步频
我们两个人，分别用两种步频去实验。我用BDD，我们组另外一个同学使用的是小步频。我在使用过程中，第一个用例写得就很大，导致直接把代码写了，这个和普通开发用时基本就一样，后续的用例添加大多是为了写而写。另一同学步频就很小，先写了大概40多个tasking，然后红绿结合一个一个实现，但是这个过程中不断重构代码，其实很多代码都可以一次实现的，为了完全实践TDD中的红绿交换导致中间多做了极多无用功。而且总有一步是需要跨越的大，感觉这种实践也并不是最佳途径。
3. 对于原有项目的改造
首先如果使用TDD就需要面向测试开发。核心关键就是业务代码可单测，可MOCK。解决方案是改造代码，构造函数中，初始化所有需要用到的成员变量。
4. Golang Mock工具的选择
经过各种比较，我们选择了github.com/stretchr/testify 作为我们的TDD的工具包，先对于其他工具包，他很全面 包含 mock assert 使用也很方便
5. 单元测试力度选择
我们加入DDD，在写代码的时候发现，其实把原有写在service上的单元测试，写在Domain层其实更合适，因为Domain层包含了所有service的调用。
6. 是否需要连接真实数据源
我们最终的做法是不连，因为如果连接数据源就很难保证单元测试在任何环境下结果一致。对于后续CI/CD不友好。全部使用testify的mock&return实现。这样做有一个缺点就是无法保证你的持久层代码的正确性。所以要额外再单独写单元测试，测试持久层代码。
7. 是否要使用TDD & DDD
看自己项目研发周期、团队水准、质量严格程度。我觉得强推自然不好，更像是一种程序员的自我修养。
