敏捷从业人员谈论测试驱动开发 （TDD），所以许多关心代码质量和可操作性的开发人员也是如此。 我曾几何时，不久前设法阅读了有关TDD的文章。 据我了解，TDD的关键是：

1. 编写测试，但失败
2. 代码，使测试成功
3. 自动化测试
4. 重构代码以提高质量
5. 重复

很容易理解。 恼火的开发人员大喊：“开发人员在编写测试吗？ 您如何期望我们开发和测试并及时完成功能？”。 毕竟，所有开发人员都不想做无聊的测试工作。 我从事开发人员大约两年了，在最初的几天里，有时我会做出这种反应。 但是随着时间的流逝，我已经开始理解软件开发的症结所在。 这次我想到尝试TDD。

我的工作涉及使用Java EE Web框架通过UI在db中连接数据库中的数据，这是典型的Web应用程序工作。

让我解释一下在采用TDD之前的测试策略：

1. 编写完整的代码，其中包括-PLSQL过程，调用PLSQL过程的Java代码，用于UI绑定的Java代码以及JSP页面本身。
2. 手动测试db层和UI层代码的功能。 它涉及导航到页面，然后测试各种操作。 在这种情况下，UI问题和后端代码问题都会出现。
3. 正如我将进一步研究UI一样，我将在代码中发现一些错误，否则将编写一个硒测试以自动测试一些用例。

通过上述3个步骤，我花了很多时间-

1. 等待后端代码编译，然后重新启动服务器以使UI反映更改。 即使它只是一个简单的1词/ 1语句更改，我也不得不等待大约5分钟，有时甚至是8分钟。 当我等待重新启动时，我会失去对其他任务的关注，因此需要一段时间才能回到主要任务。
2. 尝试调试并找出异常/错误是由于UI代码问题还是后端代码问题引起的。
3. 等待页面加载并浏览页面到正确的页面。

好的，那是史前时代。 现在正走向现代。 我以为我无法完成TDD的工作，这是因为我编写了后端和UI代码耦合不良的代码。 我想不出一种方法来独立测试后端代码，然后移至UI代码，然后通过硒测试对其进行测试。 抛开这些概念，我试了一下。 我知道我与实际的TDD距离不太远，但感觉有点接近。

1. 我对如何实现逻辑，创建基本实现并使其成功编译有一个很明确的想法。
2. 创建了一些数据填充测试，以获取用于测试的数据类型。
3. 创建了JUnits以测试基本功能。 主要是通过Java API正确执行PLSQL过程。
4. 更新了JUnits以添加更多测试以测试所需的实际功能，并更新了代码以实现这些功能。
5. 重构代码以消除难闻的气味，然后运行JUnits以确保没有任何损坏。

我感到兴奋的原因，以及我认为这是双赢的策略：

• 我开始考虑的是API用户而不是API创建者。 这使我无法添加可以解决问题但难以测试的黑客。 与以前编写的代码相比，这极大​​地改善了代码结构。
• 无需重新启动服务器，每次重新启动不会浪费〜8分钟，也不会浪费浏览页面的时间。 我只需要编辑代码，运行Junit并查看测试即可确定命运。 这对于我编写的后端代码更有用。
• 我专注于代码测试周期，因此不会失去重点。
• 我看到测试显示绿色的成就感。
• 创建具有良好单元测试的代码以测试后端功能的可能性，这也有助于更轻松地重构代码。

现在，我只需要为UI和后端编写粘合代码，并通过硒测试来测试粘合代码。

任何人开始使用TDD时都有类似的经历吗？

参考： 我在测试驱动开发中的第一步-我们的JCG合作伙伴 Mohamed Sanaulla在“ 体验无限”博客上提出的双赢策略 。