TDD的核心思想是什么？首先是规范，也就是说，表达测试案例作为表达需求的一种方式，作为对传统文档，用例等的补充。“不要简单地考虑测试从需求和设计的角度来看，案例作为测试和测试案例“本身是好的。
TDD的第二个概念首先是测试，强调测试实施的驾驶效果，首先编写测试用例，然后实现和重建。在规范的概念中以示例的概念，首先是“首先了解需求，在外部接口设计上做得很好，将其转换为测试用例，然后实现并重建它。”
如果强调实施驱动力的驱动力，那么“可以在实施之前解决需求”的假设实际上是隐含的，这是非常不现实和不现实的！用户确实可以运行效果。在实际操作中进行探索。除了简单的情况外，您能在澄清需求之后达到Linux系统吗？既然您无法实现Linux系统，那么这种称呼的需求的意义是什么？需求无法摆脱您的能力。在需求和实施之前，不是一个简单的人驱动任何人，而是相互反馈的关系，这与何种方式的方式无关在目前，我钦佩的方式是实现快速实现，在实际操作中经验效应，不断优化探索和清晰的需求。当需求达到相对稳定的水平时，请编写测试案例以巩固需求。
让我们首先谈论两者：
这里的矛盾是，敏捷发展认为可以尽快执行的程序，然后迭代需求。测试需要根据正确和完美的需求编写大量测试。编写许多测试将不可避免地花费大量时间来延迟交货。而且，恒定需求还将改变测试代码以不断更改，进一步延迟每个时期的交付。此外，存在这些矛盾：两者：
在讨论中，我们假设需求是确定的稳定。
这里的矛盾是测试单元测试将推迟集成测试的时间。如果我们想尽快进行集成测试，并且我们假设在集成测试后必须暴露某些事情，那么我们应该进行更少的单位测试，并且尽快进行集成测试。
但是上面的假设并不总是建立。在一个简单的系统中，在集成测试后必须确定任何问题。通过合理的设计，可以在编码之前确定多个端的通信（例如前端，上游和下游）。
这是指代码项中高级设计和基础设计测试的测试。
让我们谈谈任何大项目，总是将任务从顶部到底部分开，这几乎是不可避免的，但是当实现问题时，可能会从顶部出现问题。
这个问题在不熟悉的领域尤为普遍。因为在陌生的地区，任何小细节都可能成为一个点失败，从而导致整个项目的崩溃和失败。以挑战的失败为例。
从顶部进行设计，但是从底部实现的。首先，有一个移动的原型，然后连续重建整体结构。换句话说，让我们首先从底部设计到上层。从顶部进行V2的设计，...，这样的步骤改进以改进整个系统。
回到测试后，我们会发现高级别的测试不能保证没有单个点故障，整个系统崩溃，但可能会忽略一些基本问题。基础测试可以确保单个模块没有问题，但不能保证模块之间的相互作用不能成为问题。对于那些复杂且没有预设经验的项目，只完成了整体设计，然后从底层上方堆积以确保在“订购”系统中确保每层模块的正确性。没有快捷方式。
“应该完成单位测试的薄度”
虚拟研讨会：TDD有多美丽？
[转移] TDD是美丽还是不漂亮？
理查德·费曼（Richard Feynman），挑战者编号，软件工程
原始：https：//juejin.cn/post/7121929141494448159