Is unit-testing of accessors a must?

Question

For classes that have several setters and getters besides other methods, is it reasonable to save time on writing unit tests for the accessors, taking into account that they will be called while testing the rest of the interface anyway?

Answer 1

I would only unit test them if they do more than set or return a variable. At some point, you need to trust that the compiler is going to generate the right program for you.

Answer 2

I like to have unit tests for them. If an accessor does any kind of work besides simply return a field then that code will be tested appropriately.

Even if a given accessor doesn't do anything other than return a field, it might be modified later to do something extra.

Also, it's an easy way to up the number of tests being run, which many managers like.

Answer 3

If your IDE generates and manages modifications for member accessors --- you wont' be doing anything special --- then testing them really isn't important; types will match up, naming will be by a template, etc.

Answer 4

My criteria for testing is that every piece of code containing conditional logic (while, if, for, etc) be tested. If the accessors are simple getters/setters, I'd say testing them is wasting your time.

Answer 5

I think it's reasonable to save time and not write unit tests that you don't think will be particularly helpful.

While 100% test coverage is an admirable ideal, at some point you run into diminishing returns where the time you spent writing the test isn't worth the benefit you get out of having it.

You can always go back and add more unit tests later if you find situations where you decide they would be useful.

Answer 6

I think most people will say testing them is a waste of your time. In the 99% case that is true. If there's a bug in an accessor and the rest of your unit tests don't catch it indirectly then I'd start questioning why that property is there at all.

On the other hand, testing an accessor takes less typing that asking this question :)

Personally I test them. But this is a gray area for me and I don't press other people in my group to test them as long as they have sufficient coverage around the functionality of the class.

Answer 7

Usually when I consider writing unit tests I ask myself the following:

1. Is the getter/setter accessing anything on the DAL (Data Access Layer)?

If so then I would include a unit test. Just in case because if at some point in the future you decide to implement lazy loading, or something more advanced than a simple get/set, then you'll need to make sure this is working properly.

1. Is it forseable that the getter/setter will throw an exception?

The best practice for getters is to not allow them to throw exceptions at all. Setter's are another matter. However, either way, if you decide that a property might possibly throw an exception, then write a unit test for that property, both for a successful access, and for purposefully generating the exception.

Other than that I wouldn't bother, as Dan pointed out, "At some point, you need to trust that the compiler is going to generate the right program for you."

Answer 8

Our company has both kinds of people and opinions. I'm tending to not testing them specifically, as they are usually

• automatically generated
• tested in the context of another test (e.g. there's some other code making use of these accessors
• not containing any code that might break

There are exceptions though:

• When they are not simply generated 'getters' and 'setters'
• When they are part of an important API that's just provided for other users and not really tested in the context you're currently in

Both these cases might cause me to test them. The first one more than the second.

Answer 9

No-friggin way! Waste of time!

Even Bob Martin See SO podcast 41, the grandfather of Agile says no.

Answer 10

Absolutely. The idea of unit tests is to ensure that changes do not affect behavior in unknown ways. You might save some time by not writing a test for getFoo(). If you change the type of Foo to be something a little more complex then you could easily forget to test the accessor. If you are questioning whether you should write a test or not, you are better off writing it.

IMHO, if you are thinking about skipping adding tests for a method, you might want to ask yourself if the method is necessary or not. In interest of full disclosure, I am one of those people that only adds a setter or getter when it is proven necessary. You would be surprised how often you really don't need access to a specific member after construction or when you only want to give access to the result of some calculation that is really dependent on the member. But I digress.

A good mantra is to always add tests. If you don't think that you need one because the method is trivial, consider removing the method instead. I realize that the common advice is that it is okay to skip tests for "trivial" methods but you have to ask yourself if the method is even necessary. If you skip the test, you are saying that the method will always be trivial. Remember that unit tests also function as documentation of the intent and the contract offered. Hence tests of a trivial method state that the method is indeed meant to be trivial.

Answer 11

You don't have to write test for properties that contain no logic.

The only explanation to test simple properties is to boost test coverage - but it's just silly.