Is there value in unit testing auto implemented properties

It seems exceptionally heavy handed but going by the rule anything publicly available should be tested should auto-implemented properties be tested?

Customer Class

public class Customer
{
    public string EmailAddr { get; set; }
}

Tested by

[TestClass]
public class CustomerTests : TestClassBase
{
    [TestMethod开发者_开发技巧]
    public void CanSetCustomerEmailAddress()
    {
        //Arrange
        Customer customer = new Customer();

        //Act
        customer.EmailAddr = "foo@bar.com";

        //Assert
        Assert.AreEqual("foo@bar.com", customer.EmailAddr);
    }
}

---

I generally consider any code that is not performing an action to be not worth testing. This typically means that I don't test properties (auto-implemented or not) because they are just setting or returning a value.

This will change if the getter or setter of a property performs some sort of "work", like possibly returning one of two (or more) values based on the state of some other field/property/whatever.

If you have not seen it, I highly recommend Roy Osherove's book on Unit Testing. It addresses all sorts of "what to test and when" type questions, including this one.

---

What happens if you switch from auto-implemented properties to something entirely different? The test only seems redundant because you know the implementation - which you should not consider when writing tests.

Of course, this depends on the likelihood of your actually changing the implementation any time soon.

---

It depends if you're testing that an API conforms to an expected set of properties, or if, as you demonstrate, you're just testing accessing and setting the properties.

In the example you give I'd say no.

Update

Conforming to expected API; if you're accessing properties indirectly, say in a reflection/dynamic environment, and you use property and method access calls to verify an unknown API conforms to an expected one.

---

Testing setting and getting properties should occur in the context of testing a business function of the object. If there's no business function testing the property then either you didn't need the property or you need more tests. I'd suggest that you add the properties as you add the tests that need them rather than add them prior to writing any tests.

By testing the business function you're treating the code as much more of a black box from the perspective of the unit test. This allows you to switch implementation details underneath with a much smaller impact on the tests. As Refactor is an important (and often overlooked) stage of the TDD cycle this means a lot less code editing. You may also realise that (for instance) the property should not have a public setter and should be assigned by a method that performs validation and other business logic.

---

Unit testing should be confined to testing functionality that you are implementing in your application.

You should not test API/SDK that your application relies on. Partly because it's a waste of time (does your company want to pay for you to test X-Third-Party's SDK/API?), and partly because it introduces "noise" into your unit test suite. The context of your unit test library should be to just test only the code in your application.