tdd - 当应用程序 100% CRUD 时应用 TDD

Question

我经常遇到这个问题，但我不知道如何克服这个障碍。我真的很想开始学习和应用测试驱动开发(或 BDD，或其他什么)，但似乎我在想要应用的地方所做的每个应用程序几乎都只是标准数据库 CRUD 的东西，而且我不确定如何去应用它。这些对象除了保存到数据库之外几乎不做任何事情；没有需要测试的复杂逻辑。我最终需要测试一个第三方服务的网关，但我想首先完成应用程序的核心。

每当我尝试编写测试时，我最终只会测试我可能不应该首先测试的基本内容(例如 getters/setters)，但对象看起来没有其他东西。我想我可以测试持久性，但这对我来说似乎永远都不正确，因为你不应该真正访问数据库，但如果你模拟它，那么你实际上并没有测试任何东西，因为你控制了吐回的数据;就像我见过很多例子，其中有一个模拟存储库，通过循环和创建已知值列表来模拟数据库，并且测试验证“存储库”可以拉回某个值......我是没有看到这样的测试的意义，因为“存储库”当然会返回该值；它在类中是硬编码的!好吧，我从纯粹的 TDD 角度来看它(即，您需要进行一个测试，表明您的存储库需要 GetCustomerByName 方法或其他方法，然后才能编写该方法本身)，但这似乎只是遵循教条，除了它的“the way” - 除了证明方法的合理性之外，测试似乎没有做任何有用的事情。

我的想法是错误的吗？

例如，以工厂联系人管理应用程序的运行为例。我们有联系人，假设我们可以向联系人发送消息。因此，我们有两个实体:Contact 和 Message，每个实体都有共同的属性(例如名字、姓氏、联系人电子邮件以及消息的主题、正文和日期)。如果这些对象都没有任何实际行为或需要执行任何逻辑，那么在设计这样的应用程序时如何应用 TDD？该应用程序的唯一目的基本上是提取联系人列表并将其显示在页面上、显示发送消息的表单等。我在这里没有看到任何有用的测试 - 我可以想到一些测试，但它们几乎只是为了说“看，我有测试!”而不是实际测试某种逻辑(虽然 Ruby on Rails 很好地利用了它，但我并不真正认为测试验证是一个“有用”的测试，因为它应该是框架为您处理的事情)

Answer 1

“该应用程序的唯一目的基本上是提取联系人列表”

好的。测试一下。 “拉”是什么意思？这听起来像是“逻辑”。

“将它们显示在页面上”

好的。测试一下。显示正确的吗？一切都在那里吗？

“显示发送消息的表单，”

好的。测试一下。正确的领域？输入验证都有效吗？

“等等。”

好的。测试一下。查询有效吗？找到正确的数据？显示正确的数据？验证输入？为无效输入生成正确的错误消息？