数据库交互代码

Question

我正在编写一个使用数据库的小型应用程序，但我不知道如何测试这种交互。我的应用程序依赖于 5 个存储过程，我决定将它们封装在一个类中。此类提供 5 个公共(public)方法来执行过程，并在必要时将结果转换为对象集合。

我真的不知道如何以简单的方式测试我的代码，我想我可能犯了一些错误。

你觉得我的设计怎么样？有没有更好的方法来处理这些情况？

非常感谢您的帮助

编辑:在我的存储过程中，只有“插入”和“选择”查询。

Answer 1

一般来说，出于以下几个原因，我建议不要针对实时数据库进行测试:

1. 执行 SQL 会使您的测试花费很长时间
2. 数据可能会在您眼皮底下发生变化，即使没有可见的代码更改也会导致测试失败。您希望您的测试是独立的和确定性的，以便它们仅在您的代码更改时通过或失败。
3. 如果您有更新数据库的代码，则需要回滚您的更改，否则您的下一次测试运行可能会导致误报或漏报。

因此，为了进行测试，您需要伪造数据库。从这样的事情开始:

public interface IDataRepository {
    Customer GetCustomerByName(string name);
    void SaveCustomer(Customer c);
    SecurityToken Login(string username, string password);
}

class DatabaseRepository : IDataRepository { ... } // invokes your stored procedures

如果您的类需要数据库中的某些内容，请将 IDataRepository 传递到对象的构造函数中。

此设置的好处是您可以创建实现相同接口(interface)的 FakeDataRepository —— 它不调用任何东西，只返回硬编码数据。您可以为满意案例、异常案例和其他需求返回数据。

换句话说，您根本没有在测试类和数据库之间的交互——单元测试的重点是测试单个功能，而不关心应用中的其他移动部分。

---

现在，如果您需要测试您的存储过程，您应该可以直接为您的DatabaseRepository 类编写测试。

您需要在每次测试后将数据库重置为其原始状态——因此您要么在事务中运行所有内容并回滚，要么在每次测试运行时创建一个包含暂存数据的新数据库。我更喜欢后一种方法——它太容易让事务处于打开状态或忘记将其回滚，因此会破坏所有测试数据。

像这样的数据库测试可能会花费任意长的时间来执行，因此您最好创建一个单独的项目来严格测试您的数据库(尤其是如果您有几百个存储过程)。

我认为这更像是一个系统或集成测试，而不是单元测试。