EF、DAL 外观和单元测试

Question

我正在为我的一个项目创建数据访问层，它只是实体框架的一个外观接口，因此大多数底层调用除了调用实体框架方法之外不包含任何逻辑。

现在，我的一位同事说我应该对每一个方法进行单元测试，即使它们包含一个调用，在我看来这听起来太激进了，对我来说这似乎有点臃肿，是吗？

除了测试我已经做过的参数之外，这里没有真正的案例可以测试，我认为没有理由测试没有任何控制结构的方法。

你有什么意见？

/// <summary> Adds the entity to the context. </summary>
    /// <param name="entity"> The entity to add. </param>
    public void Add(object entity)
    {
        var name = GetEntitySetName(entity);

        Context.AddObject(name, entity);
    }

    /// <summary> Updates the entity in the context with the given entity data; otherwise, attaches it to the context in attempt to update the related record in the data source on the next call to commit. </summary>
    /// <param name="entity"> The entity to use for the update. </param>
    public void Update(object entity)
    {
        var name = GetEntitySetName(entity);

        var manager = Context.ObjectStateManager;

        EntityKey key = Context.CreateEntityKey(name, entity);

        ObjectStateEntry entry;

        if (manager.TryGetObjectStateEntry(key, out entry))
        {
            entry.ApplyCurrentValues(entity);
        }
        else
        {
            Context.AttachTo(name, entity);

            manager.ChangeObjectState(entity, EntityState.Modified);
        }
    }

Update 和 Add 方法中的 Context 是伪造的，但行为与真实的一样，我知道在大多数情况下这会很极端，但我们无法针对数据库对其进行测试，至少在当前阶段是这样。

因此，我的这位同事说我应该测试这个“添加”方法作为我的单元测试的一部分，这让我很困惑，他声称每个公共方法都需要单元测试。

在我看来，这似乎很激进，因为这就像质疑对实体框架的 .AddObject 的调用是否会起作用，我认为它会起作用。

我真正想知道的是，您是否会测试其中没有控制结构并且确实需要测试对 3rd 方库的调用的方法？我认为不会。

Answer 1

包含 EF 功能的测试方法不是单元测试，而是集成测试，它实际上是有原因的，因为它验证您的 DAL 正在使用真实的数据库。这不是关于测试它的参数或其他什么，而是关于测试映射是否适用于真实数据库、记录是否真正被读取或持久化等等。