tdd密码检查程序_从上到下– Web应用程序的TDD

tdd密码检查程序

我是“测试狂”，但我不理解测试驱动的开发 。 还是我想。 我已经阅读了几本书和许多博客文章，所有这些都有一个主要问题：

例子总是太简单了 。

如果您编写简单的文本编辑器或计算器来谋生，这些示例可能会有所帮助。 我不那样做，很可能你和我在同一条船上。

您可能已经知道，我使用Spring Framework编写Web应用程序为生。 让我们找出我在使用TDD时遇到的问题。

盖房子吧

当我开始执行新任务时，通常遵循以下工作流程：

1. 创建域模型对象和所需的数据库表。
2. 实现存储库层。
3. 实施服务层。
4. 实施Web层。

如您所见，我喜欢从头到尾构建内容，并且我觉得TDD不适合这种方法。 因为我从头到尾都在工作，所以通常不可能将测试用例与业务需求联系起来。 这让我感到一个测试用例没有“现实生活”的价值。 它的价值纯粹是技术性的（确保代码干净并且可以工作）。

但是，作为软件开发人员，我的首要任务是找到正确的问题并加以解决。 当我遵循此工作流程时，TDD无法帮助我做到这一点。 也许这就是为什么我觉得自己没有动力使用它的原因之一。

每次我尝试TDD时，我都觉得在编写任何代码之前弄清楚测试用例会耗费大量精力。 最终，我停止尝试并在代码完成后编写了测试。 超级容易。 毕竟，完成我的代码后，我确切地知道应该测试什么。

这可能不是一件好事 。

当我从头到尾构建应用程序时，我错过了必不可少的重要信息，这些信息经常会在后来困扰我。

要求呢？

几天前，我正从体育馆回到家，想着肯特·贝克（Kent Beck）的这则推文 ：

tdd是在考虑解决方案之前考虑问题的绝妙借口

突然间，这一切对我都有意义（锻炼似乎对您的大脑有好处）。 我意识到TDD令我感到困惑，因为我的工作流程存在缺陷。 我没有在解决方案之前考虑问题，而是从解决方案着手解决问题。

这意味着麻烦 。

如果我们考虑Web应用程序的不同层，则会注意到与解决的问题“最接近”的层是Web层。 几乎显而易见，这是我们应该开始工作的层。

让我们考虑一下，如果我们翻转旧的工作流程并从上到下开始工作会发生什么。 这意味着

1. 每一层都指定了其下一层的要求 。 这意味着我们不会编写不需要的代码。 当然，没有什么是最终的。 需求可能会更改，我们必须更改代码。 但是，这种方法可以消除由于误解需求而导致的更改。
2. 我们可以专注于需求并将其转换为测试用例 。 当所有测试用例通过时，我们就有一个可以满足给定要求的软件。 另外，由于我们了解特定组件的需求，因此即使我们尚未编写任何代码，也很容易找出所需的测试用例。

我越想这个，TDD对我越有意义。 我已经在TDD中尝试了这种“新”方法，它看起来确实很有希望。 最显着的改进是：

找出有意义的测试用例不再困难。 这很容易。

你为什么要在乎这个狗屎？

如果您不愿意挑战自己，则应该停止浪费时间，现在就停止阅读 。 我已经浪费了您宝贵的时间。

我注意到，有时开发人员认为应用程序的源代码是软件项目中最重要的交付内容。

问题是，除非我们能证明它，否则源代码没有任何价值。

1. 解决正确的问题。
2. 可以正常工作。

这就是为什么编写自动化测试很重要的原因。

令我感到遗憾的是，许多开发人员一直在寻找提高其编码技能的方法，但是只有少数开发人员正在寻找编写测试的新方法。

叫醒人！ 测试也是代码！

参考：从上到下– Petri Kainulainen博客上我们的JCG合作伙伴 Petri Kainulainen 对Web应用程序的TDD 。

翻译自: https://www.javacodegeeks.com/2013/09/from-top-to-bottom-tdd-for-web-applications.html

tdd密码检查程序