我对单元测试，TDD，测试实例，用户用例的理解

单元测试是软件测试方法，可以以一个函数，一个模块进行检验，最好就是实现自动化

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