Question

I am start using TDD for the following class using Entity Framework 4.1:

    public class Agent
    {
        // Primary key
        public int ID { get; set; }

        [Required]
        public string Name { get; set; }

        public string Address { get; set; }
        public string City { get; set; }
        public string Country { get; set; }
        public string Phone1 { get; set; }
    }

My assertion will fail:

    /// <summary>
    ///A test for Agent Constructor need have name
    ///</summary>
    [TestMethod()]
    public void AgentConstructorTest()
    {
        Agent target = new Agent();
        Assert.IsNull(target);
    }

When I look at the generated target object, it is created with ID = 0. How could I test that Name is required then?

And if the Name field is required, how could I still create an Agent object? When will the real ID been assigned? To test model itself, do I need create/mockup a DbContext to be able to assigned a ID?

Answer 1

Keep in mind that your are just dealing with POCO classes here – there is no magic going on that would allow the construction of the Agent class to fail just because you have put a custom attribute on one of its properties.

Entity framework is checking for custom attributes during its validation and for data mapping – in this case it will check for the Required attribute and only declare the entity as “valid” if the corresponding string property is not null and also it will map Name to a non-nullable column in the database.

To mirror that you could write a custom validation routine in your unit test that performs the same checks, i.e. makes sure that all properties that are decorated with the Required attribute indeed have a value, i.e something like this:

[TestMethod()]
public void AgentWithNoNameIsInvalid()
{
    Agent target = new Agent();

    Assert.IsFalse(IsValid(target));
}

This does feel like you are testing EF now though, not your code.

Since the ID is your primary key it will only be assigned when the entity has been committed to the database. So yes for full testing you will have to mock a unit of work and a context that does this for you as well. There are many pitfalls though and subtle (and not so subtle) differences between IQueryable<T> and IEnumerable<T> that makes this approach very fragile.

Personally I would recommend you do integration testing with EF based on a separate test database with known content and write your unit tests and expected results based on this test database – this might not be true TDD but I found it is the only way to be sure that I am testing the right thing.