通过 JUnit DAO 类进行测试答案

【问题标题】：Test via JUnit DAO class通过 JUnit DAO 类进行测试
【发布时间】：2015-03-24 20:28:29
【问题描述】：

我有一个 DAO 类，我需要在其中测试名为 getItemById() 的方法，该方法从 DB 的表中返回 Item 对象。

只要我明白我必须在该测试中创建一个 Item 对象并检查它是否等于从方法返回？或者我只需要检查它是否返回一个 Item 对象？

如果表为空或根本没有具有该 ID 的行怎么办？

对不起，这是一个相当新手的问题，但我无法在脑海中说清楚。请帮忙！

【问题讨论】：

您要测试一条 SQL 语句吗？你能发布你的测试代码吗？
@bigdestroyer 请...
嗯...测试数据库是一个有争议的问题。我不喜欢，。但是有工具可以做到这一点。或者您可以使用测试数据库。

标签： java maven junit dao

【解决方案1】：

对无法预测其中内容的数据库运行测试是无效的；任何有足够弹性以适应不断变化的数据的测试对于确认被测代码是否真的做正确的事情都是毫无价值的。我会让测试使用它自己的数据库实例，这样就不会有其他用户干扰我的测试，或者我的测试从其他人那里改变数据的问题。理想的选择是像H2 这样的内存数据库，测试可以实例化并在完成后丢弃。这样，测试可以在任何地方（例如在 CI 服务器上）运行，并获得相同的结果。

测试需要运行 ddl 来创建模式并在执行前填充数据库。您可以为此使用不同的工具。 DbUnit 很流行，还有一个叫做DBSetup 的替代方案应该不那么复杂。您可以针对不同的场景拥有单独的测试数据。 DbUnit 具有从数据库中提取数据的工具，可以更轻松地创建测试数据。

由于数据库在您的控制之下并且您可以根据需要填充它，因此您应该根据填充的数据验证返回的对象的字段是否符合您的预期。使测试尽可能具体。

为了测试 SQL 以及对象如何映射到结果集，使用数据库是有意义的。对于其中的某些部分，使用不接触数据库并使用模拟的单元测试是有意义的。例如，最好确认连接在所有情况下都已关闭，使用模拟比在代码中引发 SQLException 更容易。

如果注入 DBConnection 类而不是在方法中实例化，则使用模拟进行测试会更容易。如果您更改代码以注入 DBConnection，那么您可以编写一个单元测试（使用不使用数据库的模拟）来检查连接是否关闭。

【讨论】：

【解决方案2】：

要执行单元测试，您应该走三个步骤：

准备测试环境（例如，用已知的测试数据填充数据库）- 这样您就不会问表是否为空等。
执行测试并断言结果
进行清理 - 因此测试不会影响其他测试

此外，您应该测试所有场景，因为您应该处理所有场景

【讨论】：

您提供了非常常见的信息，我已经知道了。我的问题很明确...
我猜你不知道你在说什么——我的回答很清楚。测试所有场景As long as I understand I have to make an Item object in that test and check if it equals to returned from method? Or I have to just check if it returns an Item object. What i wrote is indeed very common, but this is what you were asking for. What if table is empty or no row with that id at all?。用已知的测试数据填充基础 - 检查是否返回 null，如果 id 正确。转储数据库，测试“entityNotFound”情况下的行为
好的，我如何测试我的方法是否从 db 返回了正确的数据？我可以进行测试以验证该方法是否返回 Item 实例，但我无法测试数据是否正常（但这是测试的目的；检查方法是否获取正确的数据）。
您应该为此使用单独的测试数据库。用一些已知数据填充数据库，使用你的 DAO 并断言结果的正确性。 Hibernate 允许您在运行时创建方案并执行 sql 脚本。您也可以直接从代码中执行此操作。有很多选择，但总而言之，这都是我在回答中提到的 3 个步骤。检查一些内存中的 dbms，例如 h2。