EF, DAL facade and Unit Testing

I'm in the process of creating a Data Access Layer to one of my projects, it's merely a facade interface to the Entity Framework, so most of the underlying calls contain no logic besides calling the Entity Framework methods.

Now, one of my colleagues says that I should Unit Test every single method even though they contain a single call and in my opinion this sounds too radical, to me it seems like a bloat, is it ?

There's no real case to test here besides testing the parameters which I already do, I see no reason to test methods that don't have any control structure.

What's your opinion ?

/// <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);
        }
    }

The Context inside the Update and Add methods is faked but acts like the real one, I know that in most cases this would be extreme but we can't test it against the database, at least not in current stage.

So to the point, this colleague of mine says I should test this "Add" method as part of my Uni Testing and got me really confused, he claims that every single public method requires unit test.

In my mind it seems radical because it's like questioning whether the call to .A开发者_运维百科ddObject of the Entity Framework will work, which I assume it will.

What I really want to know is whether you will test method that have no control structure in them and is really required to test calls to 3rd party libraries ? I think not.

---

Testing methods which wrap EF features is not unit testing but integration testing and it actually have a reason because it validates that your DAL is working with a real database. It is not about testing its parameters or what so ever but about testing that mapping works with the real database, that records are really read or persisted, etc.