单元测试 – EF,DAL外观和单元测试

2024年1月9日 239次阅读

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

现在,我的一位同事说我应该对每一种方法进行单元测试,即使它们只包含一个电话,而且我认为这听起来过于激进,对我来说这似乎是一种臃肿,是吗？

除了测试我已经做过的参数之外,没有真正的情况可以测试,我认为没有理由测试没有任何控制结构的方法.

你怎么看 ？

/// <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的调用是否会起作用,我认为它会.

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

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

点赞