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是伪造的，但是就像真实的一样，我知道在大多数情况下这将是极端的，但我们无法对数据库进行测试，至少在现阶段不是。

所以到目前为止，我的同事说我应该测试这个“添加”方法作为我的Uni测试的一部分，让我真的很困惑，他声称每一种公共方法都需要进行单元测试。

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

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

Answer 1

包装EF功能的测试方法不是单元测试，而是集成测试，它实际上有一个原因，因为它验证了您的DAL正在使用真实数据库。它不是关于测试它的参数或者是什么，而是测试映射是否与真实数据库一起工作，记录是真正读取还是持久化等等。

EF，DAL门面和单元测试

1 个答案: