单元测试测试行为！

Question

以下是我应用程序中的确切情况：

代码库中有几种使用实体的C＃方法与SQL数据库对话的框架。
针对所有方法编写单元测试，并涵盖基于方法签名，输入要求和返回值的所有可能的排列和组合。
单元测试工作正常，并且在应有的时候失败（即，某些验证发生更改或期望的返回值发生更改的情况，但单元测试未反映相同情况）。
在某些情况下，开发人员会对SQL模式进行更改，并使用C＃代码更新实体。在这种情况下，通过单元测试绝对是好的，因为它只是更改了其基础逻辑，而不更改了输入，验证或返回值。
但是，我希望在更改数据库架构和实体但不更改单元测试时某些单元测试会失败。这意味着，我希望开发人员在更改数据库架构和实体时修复单元测试。

任何人都可以建议如何实现相同目标吗？

对此将提供任何帮助。

谢谢

Answer 1

我在最后一段中上移了，因为它出现在您的XY problem的X处。我建议阅读所有其他段落，因为您似乎误解了单元测试的含义和目的。

单元测试不能测试多个代码库！

我刚刚在您写的评论中注意到了这一点

因此，如果一个项目的开发人员更改了数据库架构，我们想提醒他们，该架构更改也应反映在其他项目中。

单元测试不应用作同步两个原本完全不相关的代码库的方法。

这是DRY vs WET的简单应用程序：如果这些应用程序共享相同的数据库架构，则数据库架构（和相关的EF实体）应该位于两个应用程序都依赖的单个来源中。
不要重复开发同一个东西，因为当另一个改变时（这就是您现在要处理的事情），您最终不得不不断地同步一个。

例如，您可以在Nuget服务器上托管“共享数据”项目，并让两个应用程序都引用该自托管的Nuget程序包。正确配置后，每当构建应用程序时，它将获取“共享数据”项目的最新版本，从而确保两个应用程序始终使用最新版本的数据库架构。

第二种方法（如果您不想创建共享依赖项）是让您的Subversioning系统观察某些文件（例如，实体类文件夹），并在这些文件中进行任何更改时提醒您。收到警报时，您将知道要检查此更改是否影响其他应用程序的代码库。
如果我对您的理解正确，那么您实际上只是在试图获取警报，对吗？

还有其他方法可以解决此问题，而决定取决于您的基础架构和团队使用的技术。 但这绝对不应该通过手动编写脚本/伪造单元测试失败来完成。

别忘了“单元测试”中的“单元”

我希望在更改数据库架构和实体时某些单元测试会失败

单元测试测试一项（因此称为“单元”）。看来您正在编写测试两件事的测试：业务逻辑和数据库。那是一个集成测试。根据经验：

单元测试测试一个组件。
集成测试可测试多个组件之间的交互。

不要测试外部依赖项

如果要专门为EF编写单元测试（不应该这样做，但是稍后再介绍），则实际上不会在测试中包含实际的数据库。充其量，您可以声明由EF生成的SQL，而无需在数据库上运行该查询。

重复我的观点，单元测试测试了一个组件。实体框架和数据库服务器是两个不同的东西。

在使用外部组件（例如数据库服务器）时，您再次钻研集成测试领域。

仅测试您自己的代码

如前所述，您不应该测试实体框架。对库进行单元测试基本上是在完成库开发人员的工作。您不应该专心于图书馆的工作方式。如果有的话，您专门使用一个库是因为您不想想要了解它在内部的工作方式。

考虑此测试：

public void TestForAddition()
{
    var expectedValue = 2;
    var testValue = 1 + 1;

    Assert.AreEqual(testValue,expectedValue);
}

您在这里正在测试+运算符，该运算符由C＃.Net框架提供。那不是您的代码的一部分，因此您不应该对其进行测试。这个想法与EF参数相同：它不是您的代码，也不由您测试。您必须信任所使用的依赖项。

但是，如果您重载了+运算符，则应该对其进行测试（因为它是您的代码）

public static Person operator+ (Person a, Person b) 
{
   return new Person() { Name = a.Name + " " + b.Name };
}

public void TestForPersonAddition()
{
    var expectedValue = "Billie Jean";

    var billie = new Person() { Name = "Billie" };
    var jean = new Person() { Name = "Jean" };

    Assert.AreEqual(billie + jean,expectedValue);
}

这对于以EF为中心的示例意味着您不应该对实体框架进行单元测试。您应该只对代码进行单元测试，而不是EF。
但是，您可以为此编写集成测试。这样就可以实现您想要的：对现有数据库运行集成测试。如果集成测试通过，您将知道新的代码库与现有数据库兼容。如果他们不这样做，那么您就知道发生了一个值得开发人员注意的问题。

单元测试测试行为！

但是，我希望在更改数据库架构和实体但不更改单元测试时某些单元测试会失败。这就是说，我希望开发人员在更改数据库架构和实体时修复单元测试。

因此，您希望开发人员修复从未被破坏的单元测试吗？

您的意图对我没有意义。您已经更改了一些代码，并且单元测试没有失败。这是一件好事。但是您想使失败，因此您的开发人员被迫“修复”单元测试（首先没有被破坏）。

如果单元测试通过了，但您仍然声称应用程序的行为有问题，则表明单元测试没有完成应有的工作。 >

您正在滥用单元测试。问题不是试图弄清楚如何迫使单元测试失败；问题是您期望单元测试的结果告诉您什么。
单元测试不应用于测试内部系统是否已更改。 单元测试测试应用程序是否仍然以相同的方式运行（即使某些代码已更改）。

如果我从头开始重写您的代码库，然后在新的代码库上运行相同的（未修改的）单元测试，并且所有单元测试都通过了，这意味着我的代码的行为与您的代码相同并且我们的代码库在功能上是彼此等效的（至少就您编写测试所针对的行为而言）

更改数据库架构和实体但不更改单元测试时，单元测试将失败

1 个答案:

单元测试不能测试多个代码库！

别忘了“单元测试”中的“单元”

不要测试外部依赖项

仅测试您自己的代码

单元测试测试行为！