1

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?

1 Answer 1

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.