6

我想为我的软件开发项目使用 Visual Studio 中的 Microsoft 测试框架实现自动化测试。我创建了一些测试，总而言之，它非常易于使用。

测试业务对象有哪些更好的实践，更具体地说，是读取和写入数据库的那些。

最好从开发数据库中设置一个单独的测试数据库，从中测试用户界面，然后针对该数据库进行测试？基本上只是用垃圾数据填充它。

在自己的心态之后接受某种类型的清理是否更好，这意味着，如果我正在测试 AddUser 方法，我是否要添加用户，检查我的测试，然后删除用户？

您是否在单个测试方法中测试每个 CRUD 方法？

最后，如何验证字符串大小是否正确、开始日期小于结束日期、CustomerId 是正确的 Customer 等各个业务规则。

我意识到这是一个相当广泛的问题......只是寻找一些方向......采取婴儿步骤。

更多信息...

很多很好的答案！我不确定我是否能够建立一个模拟数据库。我使用 CSLA 作为我的对象的框架。需要进行一些认真的重构才能使用模拟对象进行测试。我要调查一下。虽然，在某些时候，我确实想测试数据库交互......当使用模拟数据库时，您将在哪里/何时实际测试数据库通信？

另一个问题......是否最好让每种测试方法不依赖于其他测试？

4

8 回答 8

8

理想情况下，您将拥有不直接访问数据库但使用辅助对象或某种 ORM（对象关系映射）框架的业务对象。然后你可以在没有数据库的情况下测试你的 BO，可能会模拟一些帮助对象。这可能是最干净的方法，因为您避免了真实数据库的复杂性，并且实际上只测试您的业务逻辑。

如果您无法避免将业务规则和数据库访问组合到一个类中（可能是有问题的设计，但有时很难避免），那么您必须针对数据库进行测试。

几乎唯一合理的选择是拥有一个单独的数据库进行自动测试。您的测试方法应该在设置时删除所有设置，然后加载所有数据，进行测试并验证结果。

甚至不要考虑尝试初始化数据库一次，然后对相同的数据运行所有测试。一项测试会意外更改数据，而其他测试会神秘地失败。我已经做到了并且后悔了……每个测试都必须独立存在。

为此，我强烈推荐某种数据库测试框架。这些可以帮助您清理数据库、加载必要的数据并将查询结果与预期结果进行比较。我使用 DBUnit（用于 Java），但还有很多其他语言用于其他语言。

于 2009-02-14T04:20:59.177 回答
5

我建议实现您的业务对象，以便他们不知道数据库。使用数据访问层上的方法，这些方法可以根据业务对象的类型正确保存/检索业务对象（即，它在表和它们对应的对象之间具有内部映射）。当测试您的业务对象本身时，您根本不必担心数据库。只需创建对象，也许使用反射来设置私有字段，然后对对象进行测试。

在测试需要与数据访问层交互的代码时，使用模拟来创建模拟数据层并在其上设置期望以返回所需的对象或正确响应保存。您可能需要将数据层开发为接口（如果使用不直接支持模拟的刚性框架，则使用可模拟类包装它）。大多数模拟框架要求方法是虚拟的以允许创建模拟实现。使用接口强制实现类中的方法是虚拟的，因此模拟要容易得多。

于 2009-02-14T04:17:48.687 回答
2

使用依赖注入。在接口中实现您的数据库方法。然后用控制数据编写接口的新实现来测试适用场景。

于 2009-02-14T04:25:28.370 回答
2

有关使用 CSLA 的 TDD 的更多信息，请参阅此问题的答案。尤其是这个。

这个问题也可能很有趣。

于 2009-06-06T19:37:07.267 回答
1

通常我创建 BO，将其保存到夹具设置中的数据库，然后对各种插入/更新/选择进行测试，然后在我的拆解中从数据库中删除对象。它使事情变得干净整洁，尤其是在涉及很多约束时，如果您不删除在测试中创建的所有内容，您的测试数据库可能会很快变得混乱。

于 2009-02-14T03:28:26.450 回答
1

要测试数据库访问层，您不应在同一个数据库上运行所有测试。有些测试可能会失败，因为它们依赖于其他测试的结果。所以这不是你想要的。实际上在每次测试之后，您应该将 db 状态恢复到测试运行之前的原始状态。

在我的实践中，我将测试数据集保存在 XML 中，并且在每次测试之前，它使用 XML 在 db 中设置数据。因此，每个测试都针对某个数据集运行。

于 2009-02-14T04:38:18.823 回答
1

我支持曾经的说法，即您应该使用 moched 数据库测试您的业务对象。在某些情况下，您可能希望将数据作为测试的一部分保留下来。这样做的缺点是运行时间更长的测试和清理的需要。

一种可能对您有所帮助的解决方案是使用内存数据库进行测试。例如，SQLite 允许您动态创建内存数据库，而当您处理它们时，它们就消失了。这使您的测试更快，并且您不必设置清理代码 - 而您实际上可以通过自动化测试来测试您的 SQL / db 代码。

于 2009-02-14T09:37:23.270 回答
0

（我知道你不使用 Java，但下面的一般策略根本不依赖于 Java）

我正在开发一个使用大量 EJB3/JPA 代码的 Java 项目。我决定创建一种能够“部署”EJB 并使用带有休眠实体管理器的内存数据库 (HSQL) 的模拟容器。

这个“容器”在不到 1 秒的时间内启动，允许我测试大多数业务组件，包括那些通过 JPA 访问数据库的组件。例如，如果一个服务太复杂而无法支持，那么我只需使用 EasyMock（或任何其他模拟库）来创建一个假服务并插入“容器”。

到目前为止，这是一个巨大的成功，但需要我几天时间来实施模拟基础设施。

于 2009-02-24T18:28:33.790 回答