在数据库而不是假存储库上运行测试是一种不好的做法吗？

StackOverflow https://stackoverflow.com/questions/607620

题

我知道优点是什么，并且当我使用更复杂的系统时，我会使用假数据。

如果我正在开发一些简单的东西，并且我可以轻松地在真实数据库中设置我的环境，并且所访问的数据非常小，以至于访问时间不是一个因素，并且我只运行一些测试，该怎么办？

创建假数据仍然很重要，还是我可以忘记额外的编码并直接跳到真实的数据？

当我说真实数据库时，我指的不是生产数据库，而是测试数据库，而是使用真实的 DBMS 和与真实数据库相同的模式。

有帮助吗？

解决方案

使用假数据而不是真实数据库的原因是：

  1. 速度。如果你的测试很慢，你就不会运行它们。模拟数据库可以使您的测试运行得比其他方式快得多。
  2. 控制。您的测试必须是测试数据的唯一来源。当您使用虚假数据时，您的测试会选择您将使用哪些虚假数据。因此，您的测试不会因为有人将数据库置于不熟悉的状态而被破坏。
  3. 订单独立性。我们希望我们的测试能够以任何顺序运行。一项测试的输入不应依赖于另一项测试的输出。当您的测试控制测试数据时，测试可以彼此独立。
  4. 环境独立性。您的测试应该可以在任何环境中运行。您应该能够在火车上、飞机上、家里或工作时运行它们。他们不应该依赖外部服务。当您使用虚假数据时，您不需要外部数据库。

现在，如果您正在构建一个小型应用程序，并且通过使用真正的数据库（例如 MySQL）您可以实现上述目标，那么请务必使用该数据库。我愿意。但请不要误会，随着应用程序的增长，您最终将面临模拟数据库的需要。没关系，需要的时候就做吧。亚格尼。只要确保您在需要时确实这样做即可。如果你放手，你就会付出代价。

其他提示

这取决于你想要测试的内容。通常，您希望测试代码中的实际逻辑而不是数据库中的数据，因此设置完整的数据库只是为了运行测试，这是浪费时间。

还要考虑维护测试和测试数据库的工作量。使用数据库测试代码通常意味着您正在测试整个应用程序，而不是单独测试不同的部分。这通常会导致大量工作使数据库和测试保持同步。

最后一个问题是测试应该独立运行，因此每个测试应该在其自己的数据库版本上运行，或者使其处于与测试运行之前完全相同的状态。这包括测试失败后的状态。

话虽如此，如果你真的想在你的数据库上测试，你可以。有一些工具可以帮助设置和拆除数据库，例如 dbunit 。

我看到有人试图像这样创建单元测试，但几乎总是它变得更加有效，然后才真正值得。大多数人在项目中途放弃了它，大多数在项目期间完全放弃了ttd，认为经验转移到一般的单元测试。

所以我建议保持测试简单和隔离，并将代码封装得足够好，可以单独测试代码。

我认为这取决于您的查询是否在存储库中修复（更好的选项，IMO），或者存储库是否公开了可组合查询;例如 - 如果您有一个存储库方法：

IQueryable<Customer> GetCustomers() {...}

然后您的用户界面可以请求：

var foo = GetCustomers().Where(x=>SomeUnmappedFunction(x));

bool SomeUnmappedFunction(Customer customer) {
   return customer.RegionId == 12345 && customer.Name.StartsWith("foo");
}

这将传递基于对象的虚假回购，但实际数据库实现将失败。当然，您可以通过让存储库在内部处理所有查询（无外部组合）来使其无效;例如：

Customer[] GetCustomers(int? regionId, string nameStartsWith, ...) {...}

由于无法编写，因此您可以单独检查数据库和UI。使用可组合查询，如果您希望它有用，则必须始终使用集成测试。

这取决于数据库是否由测试自动设置，以及数据库是否与其他开发人员隔离。

目前它可能不是问题（例如，只有一个开发人员）。但是（对于手动数据库设置）设置数据库是运行测试的额外障碍，这是一件非常糟糕的事情。

如果您只是编写一个简单的一次性应用程序，而您绝对知道这种应用程序不会增长，那么我认为很多“最佳实践”。走出窗外。

如果您所写的所有内容都是简单的“联系我们”，那么您 形成。但是，在“简单”和“简单”之间画线的位置。应用程序和“复杂”应用程序一个很难。

换句话说，请使用您的最佳判断，因为没有对此有任何难以解决的答案。

只要您没有将它们视为“单位”，就可以为该方案执行此操作。试验。那些将是集成测试。您还需要考虑是否要一次又一次地通过UI手动测试，因为您可能只是自动进行烟雾测试。鉴于此，您甚至可以考虑不进行集成测试，只需在功能/ ui测试级别工作（因为它们已经涵盖了集成）。

正如其他人所指出的那样，很难在复杂/非复杂的情况下划清界线，而现在你通常会为时已晚:(。如果你已经习惯了这样做，我相信你赢了'如果不是这样，你可以从中学习：）

就真实数据库不妨碍你而言，你可以更快地走这条路，我会务实并且去追求它。

在单元测试中，“测试”是指单元测试。比“单位”更重要。

假设您要自动执行此操作，最重要的是您可以以编程方式生成初始条件。听起来就是这种情况，甚至更好的是你在测试现实世界的数据。

然而，有一些缺点：

您的真实数据库可能无法涵盖代码中的某些条件。如果您有假数据，则会导致该行为发生。

正如您所指出的，您有一个简单的应用程序;当它变得不那么简单时，你会想要进行测试，你可以将它们分类为单元测试和系统测试。单元测试应该针对一个简单的功能，使用虚假数据更容易。

虚假存储库的一个优点是您的回归/单元测试是一致的，因为您可以预期相同查询的结果相同。这样可以更容易地构建某些单元测试。

如果您的代码（如果不是仅读取查询）修改数据，则有几个缺点： - 如果您的代码中有错误（这可能是您正在测试的原因），您最终可能会破坏生产数据库。即使你没有打破它。 - 如果生产数据库随着时间的推移而发生变化，特别是在您的代码执行时，您可能会丢失所添加的测试材料，并且很难在以后将其清除出数据库。 - 来自访问数据库的其他系统的生产查询可能会将您的测试数据视为真实数据，这可能会破坏重要业务流程的结果。例如，即使您使用某个标志或前缀标记了数据，您是否可以确保访问数据库的任何人都遵守此模式？

此外，某些数据库受隐私法管辖，因此根据您的合同以及谁拥有主数据库，您可能会或可能不会合法地允许您访问实际数据。

如果您需要在生产数据库上运行，我建议您运行一个可以在高峰时段轻松创建的副本。

这是一个非常简单的应用程序，你看不到它的增长，我认为在真正的数据库上运行测试没有问题。但是，如果您认为此应用程序会增长，那么在测试中考虑这一点非常重要。

尽可能保持一切尽可能简单，如果您以后需要更灵活的测试，请尽量做到。提前计划，因为你不想在3年内拥有一个依赖于旧的和hacky（用于大型应用程序）测试的庞大应用程序。

针对您的数据库运行测试的缺点是缺乏速度以及在运行测试之前设置数据库状态的复杂性。

如果您可以控制这个，那么直接针对数据库运行测试没有问题;它实际上是一种很好的方法，因为它比伪造数据运行更能模拟您的最终产品。关键是采取务实的方法，并将最佳实践视为指导而非规则。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top