单元测试是软件测试方法，可以以一个函数，一个模块进行检验，最好就是实现自动化
TDD 是一种实现循环现实的东西，首先关注检验点，如函数输出值，第二，运行为什么程序不正确，第三写代码，第四，在检验，第五，重构，第六在检验，不断重复，(先写测试，在写代码，在检验，在重构，在检验模式)
测试用例是跟着业务走的功能点，是一个整体检验，业务检验, 根据输入，处理，输出做检验，检验实例化需求
用户用例是用户使用产品的场景，可根据使用场景列出测试用例
我们需要思考的一样东西是，简单设计，符合实际需求，要从根源，目的，从流程中解决，而不是换一种新技术
其关系是
用户实例是根据文字需求产生的，用户事件动作流程图
测试用例，是检验每个动作的是否正确，符合实际
单元测试是开发，把功能点拆成一个个独立功能点去进行检验，可以使用TDD 方法模式进行, 也可以按照瀑布流的方式，写完代码在写测试
引用coolshell 里面的一段话
“当你的软件开发出现问题的时候，就像bug-fix一样，首要的事是找到root cause，然后再case by case的解决，千万不要因为有问题就要马上换一种新的开发方法”
总结
凡是要找问题，而不是立刻转换，要搞清楚根本，保证质量，有很多方法，要分析利益，拆细处理，可以应用测试单元，单不要迷信要做多好，他的目的都是为了程序稳定运行，早发现问题
参考资料
“单元测试要做多细？”
https://coolshell.cn/articles/8209.html
TDD并不是看上去的那么美
https://coolshell.cn/articles/3649.html
十条不错的编程观点
https://coolshell.cn/articles/2424.html
use case
https://en.wikipedia.org/wiki/Use_case
test case
https://en.wikipedia.org/wiki/Test_case
Unit testing
https://en.wikipedia.org/wiki/Unit_testing
TDD
https://en.wikipedia.org/wiki/Test-driven_development
ATDD - 针对开发 - 测试 - 业务相互沟通进行编码，模式先用大家共同语言，转变成，代码语言，目的是看是否立刻满足需求，在去细化，这个难点是需要使用一些可视化，语言化的工具，生成既见既所得的效果才有效
https://en.wikipedia.org/wiki/Acceptance_test%E2%80%93driven_development
Behavior-driven development - 是TDD的扩展，使用一些自然语言来生成，要测试的内容
https://en.wikipedia.org/wiki/Behavior-driven_development
