我一直在阅读关于敏捷，XP方法和TDD。
我一直在项目中说明它需要做TDD，但大多数测试是以某种方式集成测试或在项目期间TDD被遗忘，努力完成代码更快。
所以，就我的情况来说，我有书面单元测试，但我发现自己将开始编写代码，而不是编写测试。我觉得有一个思想/设计/范式的变化，这是巨大的。所以，虽然一个真正相信TDD，你实际上最终回到旧风格，因为时间压力/项目可交付成果。
我有几个类，我有纯单元测试代码，但我似乎不能继续的过程，当mocks进入图片。另外，我有时看到：“为它写一个测试是不是太微不足道”综合症。
你怎么认为我应该处理这个？
我发现有趣的是，迄今为止的任何反应都没有涉及我认为是对现代开发实践的基本洞察，也就是说，通过收集需求，进行分析和建模所需的软件的“老式”方式系统在编写任何代码之前实际上有很多事情要做。
TDD实际上体现了这一点。
要写一个测试，你首先必须知道 – 用非常简单的术语 – 你的输入将是什么，你期望的输出将是什么。
一旦你有了这些知识，你可以编写一个测试来练习一些神话代码，以及在一定程度上，在编写代码本身或创建这些工件之前，代码将与之交互的其他工件。
这就是我们以前在“瀑布”方法中称为“需求工程”和“系统分析”。
除此之外，你会发现，一旦你掌握了这个级别的需求，写测试就会自然而然地发生(毕竟，它只是那些需求中体现的功能语句的代码中的表达式)。
在编写以测试形式表达需求的代码时，在以可执行代码的形式向项目提交这些空白和误解之前，您将找出需求中的差距和误解。
对于“敏捷”的现代从业者，承认他们从事一系列“瀑布”的方法，我认为太尴尬了，所以这需要工程和理解被混淆在语言背后的需要解决这些事情的语言同时试图拼命地避免承认“敏捷”(通常被理解，或者可能被误解)将婴儿抛出大部分的洗澡水。
