写入单元测试查询数据库的方法

Question

我正在学习TDD，我目前有一种方法可行，但我认为我可以使用TDD重建它。

该方法基本上需要6个参数，查询数据库，执行一些逻辑并返回List<T>

我的初步测试包括检查空/零定义的字符串和int方法参数值，但现在我不知道该怎么做。如果我没有使用TDD，我只需创建代码来查找数据库连接字符串并打开数据库连接，查询数据库，读取值等。

显然我们不能在单元测试中这样做，所以我在听取了一些如何进行的建议。

Answer 1

请记住，TDD与良好的设计有关，而不是测试。这种方法有太多的进展;它违反了“关注分离”原则。

您已经确定了需要测试的几个方面：

  

该方法基本上需要6个参数，查询数据库，执行一些逻辑并返回List<T>

那里有几个不连续的步骤，代码中可能还有一些隐藏的步骤。打破这些是TDD游戏的名称。

对于初学者来说，分解执行逻辑的部分可能是个好主意。

您的方法是否动态构建查询？打破这一部分并测试它以确保查询正确写入。

您可以将查询的执行放入独立的存储库或类似的存储库中，并针对该存储库编写集成测试。这样，您只需要对数据库进行简单的测试，而不是使用当前的复杂方法。

如果您尝试按原样进行测试，您可能最终会进行怪物测试，需要进行大量设置并复制您的所有业务逻辑，并且当它打破时，它将不清楚出了什么问题。

Answer 2

一般来说，使用TDD测试数据库代码并没有“错误”。但是，您可能会尝试抽象出数据库代码，然后嘲笑它。

Answer 3

  

该方法基本上需要6个参数，查询数据库，确实如此   一些逻辑并返回一个List

对于单元可测试代码来说，似乎 太多了

单元可测试代码应该做非常具体的事情，并在小模块中进行。所以，在你的情况下，你需要重构并破坏你的方法（至少）：

• 数据库查询：包含在具有后备接口的DataProvider中。你的单元测试会模仿这个界面。
• 做了一些逻辑：这是单元测试的最佳候选者。这应该是一个只接受数据提供者接口并执行逻辑并返回修改后列表的模块，您将在单元测试中验证该列表。

此外，请记住，单元测试应涵盖每个可测试模块的至少三个方案：

• 积极的测试
• 负面测试
• 测试为无效值抛出有意义的异常。

希望这有用。

Answer 4

另一种选择是在测试之前启动事务并在之后进行回滚。这种方式测试是独立的，因此根据一些定义，仍然可以考虑单元测试。

与其他答案中提到的内容相反，您应该重构代码，以便在测试通过后获得更好的设计。然后，您可以通过重新运行测试来验证您的重构没有破坏任何内容。

Answer 5

您可能想尝试查看DbUnit在数据访问层上运行单元测试。它使您的数据库在测试运行之间处于已知状态，从而防止测试数据库损坏。

Answer 6

你可以：

1. 使用class / test init引发空白数据库或带有已知数据集的小型DB副本。
2. 在测试方法中输入测试数据（如果DB为空），然后执行查询，然后将结果与期望结果进行比较。
3. 在测试/类清理中删除DB。

这测试你的单位但被一些人认为是“整合测试”。 - 由于“单位”一词含糊不清，“单元测试”一词存在一些分歧。

您还可以使用内存数据库或进程内数据库来简化测试环境。