Should I write redundant unit tests for property setters/getters?

Question

Given: I have a policy of writing thorough, automated unit tests for every externally visible element of an application/system.

Given: I have an API that includes accessors for a property.

The accessors look like this:

getA()::
    return A
setA( a )::
    A = a

Unit tests for the accessors are identical:

setATest::
    exp = 0
    setA( exp )
    act = getA()
    assert( exp == act )
getATest::
    exp = 0
    setA( exp )
    act = getA()
    assert( exp == act )

Question: as a matter of policy, should I always have a separate unit test for both accessors, or is one unit test, "testSetGetA", sufficient?

Answer 1

If your policy is to write at least one automated unit test for every externally visible element of the application/system, then I would expect that you would have at least one automated unit test for your accessor and mutator methods. I would also expect that those tests follow any other standards - organizational or generally accepted good practices - for unit tests, which would likely call for separate unit tests for each method.

I would question the value of the policy requiring unit tests for this type of code, though. It's simple enough that it is easily inspected. If the methods are generated, then I wouldn't expect generated code to need to have explicit unit tests. However, if you have any kind of data transformation or validation in either, then I would consider capturing those rules in the form of unit tests to continue to assert that the transformations and validations remain in place and unchanged.