unit-testing - EF、DAL 外观和单元测试

Question

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

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

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

你的意见是什么？

/// <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 方法中的上下文是伪造的，但其行为就像真实的上下文一样，我知道在大多数情况下这会很极端，但我们无法针对数据库对其进行测试，至少在当前阶段无法进行测试。

所以，我的这位同事说我应该测试这个“Add”方法作为我的统一测试的一部分，这让我很困惑，他声称每个公共(public)方法都需要单元测试。

在我看来，这似乎很激进，因为这就像质疑对 Entity Framework 的 .AddObject 的调用是否有效，我认为它会有效。

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

Answer 1

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