c# - 努力-伪造数据库时FirstOrDefault返回null

Question

我正在尝试为我的项目创建一些单元测试，经过大量挖掘之后，我发现了Effort，这个想法很棒，它模拟数据库而不是处理伪造的DBContext，顺便说一句，很难做到正确使用复杂的架构。

但是，我将用户的电子邮件特别添加到Effort创建的内存数据库后，尝试获取用户的电子邮件，这是代码

MyContext contextx = new MyContext(Effort.DbConnectionFactory.CreateTransient());

var client = new Client
{
    ClientId = 2,
    PersonId = 3,
    Person = new Person
    {
        PersonId = 3,
        EMail = "xxxxx@gmail.com"
    }
};
contextx.Client.Add(client); //<-- client got added, I checked it and is there

var email = contextx.Client.Select(c => c.Person.EMail).FirstOrDefault(); 

在上面的最后一行中，我无法使其返回电子邮件xxxx@gmail.com，而是始终返回null。

有任何想法吗？

Answer 1

回答您的直接问题

对于您提出的具体问题，我建议两件事：


查看contextx.Client.ToArray()并查看您实际上在该集合中有多少个成员。 Client集合实际上可能是空的，在这种情况下，您确实会得到null。或者，可能是Client集合中的第一个元素的EMail值为空。
如果在DbContext上查询contextx.SaveChanges()集合之前调用Client，行为将如何改变？我很好奇，看看是否调用SaveChanges会导致新插入的值存在于集合中。确实不需要这样做，但是在Effort和DbContext之间可能会有一些奇怪的交互。


编辑：SaveChanges()原来是答案。

一般测试建议

由于您使用“单元测试”标签来标记此问题，因此，根据我作为单元测试从业人员和教练的十年经验，我将提供一些常规的单元测试建议。单元测试是关于隔离测试应用程序的各个小部分。通常，这意味着单元测试一次只能与几个类交互。这也意味着单元测试不应依赖于外部库或依赖项（例如数据库）。相反，集成测试一次练习系统的更多部分，并且可能对数据库等事物具有外部依赖性。

尽管这似乎是对术语的qui贬，但这些术语对于将测试的实际意图传达给团队的其他成员很重要。

在这种情况下，您要么真的要对依赖于DbContext的某些功能进行单元测试，要么尝试测试数据访问层。如果要编写直接依赖于DbContext的对象的隔离单元测试，则需要打破对DbContext的依赖。我将在下面的“打破对DbContext的依赖性”中对此进行解释。否则，您实际上是在尝试集成测试DbContext，包括如何映射实体。在这种情况下，我总是发现最好隔离这些测试并使用真实的（本地）数据库。您可能想要使用与生产中使用的相同种类的本地安装数据库。通常，SqlExpress可以正常工作。将您的测试指向数据库实例，测试可以完全破坏这些实例。在运行每个测试之前，让您的测试删除所有现有数据。然后，他们可以设置所需的任何数据，而不必担心现有数据会发生冲突。

打破对DbContext的依赖

那么，当您的业务逻辑依赖于访问DbContext时，如何编写好的单元测试？你不知道

在使用Entity Framework进行数据持久化的应用程序中，我确保对DbContext的访问包含在单独的数据访问项目中。通常，我将创建实现存储库模式的类，并允许这些类依赖DbContext。因此，在这种情况下，我将创建一个实现ClientRepository接口的IClientRepository。该界面如下所示：

public interface IClientRepository {

    Client GetClientByEMail(string email);

}

然后，任何需要访问该方法的类都可以使用基本存根/ mock /任何东西进行单元测试。不必担心模拟出 DbContext。您的数据访问层已包含在内，您可以使用真实的数据库进行全面测试。有关如何测试数据访问层的一些建议，请参见上文。

另外一个好处是，该接口的实现定义了在单个统一的位置通过电子邮件地址查找 Client的含义。 IClientRepository界面使您可以快速回答以下问题：“我们如何在系统中查询 Client实体？”

对 DbContext的依赖与允许域类对连接字符串具有依赖并且到处都具有ADO.Net代码的测试问题的范围大致相同。这意味着您必须创建一个包含真实数据的真实数据存储（即使使用伪造的db）。但是，如果您将对 DbContext的访问包含在特定的数据访问程序集中，则会发现单元测试更容易编写。

对于项目组织，我通常只允许我的数据访问项目引用Entity Framework。我将有一个单独的Core项目，在其中定义实体。我还将在Core项目中定义数据访问接口。然后，将具体的接口实现放入数据访问项目中。然后，解决方案中的大多数项目都可以简单地依赖Core项目，而只有顶级可执行文件或Web项目才真正需要依赖数据访问项目。