我有这个类，我想用TDD构建，但我失败了。它是一个非常基本的类SubMissions，它只是从SQL数据库中获取一些数据。
所以它有getSubMissionForPage()，getSubMissionFromId()等方法。
我尝试使用TDD构建它。我的第一个测试包含对getSubMissionPage()的调用，其唯一目的是返回数据。所以让这个测试失败是相当困难的，因为它可以返回任何数据，我无法想出一种让它失败的方法。
我知道让你的测试失败是知道要实现什么的第一步，但是如果实际上没有办法让测试失败，你会怎么做？
答案 0 :(得分：8)
每当您依赖外部数据源时，您的测试总是会失败。如果连接被丢弃到您的数据库怎么办？如果表中不存在您尝试从中获取数据，该怎么办？如果您获得的数据不是您期望的数据怎么办？
测试连接到DB的类比测试HelloWorld.java要棘手一些，因为你需要某种方式来mock the DB。您可以详细了解Mock Objects here。
简短的回答，您的测试/软件总是会失败。如果你认为你的测试不能失败，你就不会对问题空间进行足够的思考。
答案 1 :(得分：5)
从数据库中检索不是从TDD开始的地方。
你可能会在网上看一些TDD的例子。 Bob Martin的bowling game scoring是一个有趣的起点。
有人说......
我的第一个测试包含对getSubMissionPage（）的调用，其唯一目的是返回数据。所以让这个测试失败是相当困难的，因为它可以返回任何数据，我无法想出一种让它失败的方法。
目的不是返回数据，而是返回正确的数据。
对此进行测试的方法是为其提供一个数据库，该数据库应该返回特定的结果并查看它。当然，直到你编写正确的代码才会这样，所以你先看了测试，然后看到真正的实现失败了。
TDD涉及数据库的困难部分是，使用真实数据库进行测试可能会很慢并且使测试可重复性很难，因为您的测试有时会更改数据。要处理这些问题，您可以从DbUnit等工具获得帮助，模拟JDBC，使用内存数据库，并使用回滚来确保您的测试不会进行永久性更改。
但你最好不要从数据库的东西开始。
答案 2 :(得分：3)
TDD的美妙之处在于，如果您发现难以编写的测试，则表明设计中存在潜在的问题。在这种情况下，您的数据访问逻辑的抽象。
例如，您可以使用依赖注入将接口发送到数据访问存储库（在测试用例中使用假或模拟），这样您就可以将数据访问测试与逻辑测试隔离开来。即构建一个处理数据访问的SubmissionRepository，您的提交类处理业务逻辑，进入存储库以进行基本的crud和整形操作。
当然，在某些时候，您需要测试一些数据访问作为集成测试的一部分，但我总是使用从TDD开始的练习来帮助推动更多的解耦设计。
答案 3 :(得分：3)
如果您希望测试失败，请让该方法抛出RuntimeException。 Eclipse将为您填写具有合适的UnsupportedOperationException的方法存根。
然后，为了使测试变为绿色，只需让方法返回null而不是抛出。
根本不需要连接数据库，直到额外的测试或两次强迫你。
答案 4 :(得分：2)
好。有一些标准类型的东西要测试：null和空字符串泉水。如果数据真的可以是任何东西，那么任何东西都是有效的。
从测试数据库开始可能不是深入研究TDD的最佳方式。从没有依赖关系的类开始。想象一下国际象棋游戏，您可能会有以下类：
我会从Location开始，因为它没有依赖关系，然后是Square，因为它只取决于Location，然后是Board，因为它只取决于Square。
答案 5 :(得分：1)
'getSubMissionPage'不应该只返回任何数据 - 它应该发出特定请求，然后根据请求返回somehing。
您需要配置“SubMissions”以使用模拟数据源，然后测试该类是否对其进行了Corrext请求并将数据正确映射到对象中。
答案 6 :(得分：0)
您不必为每种方法编写测试。如果您认为测试太简单而无法破解，您可以决定不为其编写测试。有些人会说你仍然应该写一个测试，但我认为有些情况你不需要。
看一下这个JUnit FAQ：http://junit.sourceforge.net/doc/faq/faq.htm#best_3
答案 7 :(得分：0)
（1）和（2）只是练习，可以帮助您确保测试正常。
现在问自己一个问题：测试失败的原因是什么？我认为在你的情况下，原因列表如下： 1.没有连接到DB 2.错误的数据库架构 3.数据不一致
以下是模拟这些原因的方法： 1.关闭数据库或更改用于连接的凭据/ jdbc URL。 2.删除有趣的表或更改其列的名称。 3.使数据不一致有点困难。这通常在未正确定义DB约束时发生。有时人们这样做是为了使架构更通用。如果不是你的情况就忘了＃3。
祝TDD好运！ 我相信将来您的测试场景将变得更加复杂。