How do you do unit tests for getters and setters?

Question

I am new to tdd and the mockito web framework.

Basically this is the getter method in the class:

public Long getDeviceManufactureId()
{
    return deviceManufacturerId;
}

How would I write a unit test?

so far I am thinking this:

dem is the name of the class

@Test
public void testGetDeviceManufactureIdreturnsDeviceManufactureId()
{
    assertEquals("Richard", dem.getDeviceManufactureId());
}

possible duplicate of [Should unit tests be written for getter and setters?](http://stackoverflow.com/questions/6197370/should-unit-tests-be-written-for-getter-and-setters) — Semih Eker, Dec 16 '14 at 16:23
I tend to agree that getters and setters are "too simple to test". For that matter, consider using Groovy; it generates them automatically with no boilerplate involved. — chrylis -cautiouslyoptimistic-, Dec 16 '14 at 16:25
@chrylis my manager wants us to increase test coverage and so getters and setters are an easier way to do this i thought... — BlueShark, Dec 16 '14 at 16:29
@SemihEker i see why you have done that. although it is not a case of should they be written. i need to do them so i need a solutiob — BlueShark, Dec 16 '14 at 16:29
note that some coverage tools allows to ignore trivial methods like getters/setters. What is your tool? — Jayan, Dec 16 '14 at 16:36
Agreeing with @chrylis. Increasing coverage numbers this way is the wrong way to go. Coverage should be used as a developer/team tool to find missing 'real' unit or functional tests, not as a management tool for whatever their reason may be. Sorry to hear that you are working in an immature environment. Try to point this out in a 'nice' way and focus on real bugs instead. — Jocce Nilsson, Dec 16 '14 at 16:43
appreciate/agree with the comments. we are under a bit of pressure but perhaps the cheap option is not the correct one — BlueShark, Dec 16 '14 at 21:00
ps the thing they want is at least 80 but ideally 100% coverage of all classes. so surely that would require doing get/setters ? — BlueShark, Dec 16 '14 at 21:01

score 6 · Accepted Answer · answered Dec 16 '14 at 16:37

In general we write test cases for methods that has some logic in it. Like service methods that may have multiple dao calls. Simply writing test cases for all method does not make sense and usually wastage of time in build (however small that is). So my opinion would be not to write such trivial test cases.

If it is just about code coverage then I am sure getter/setters will be used in some other method that will have a test for it. That should cover these. But if you absolutely have to write a test case then what you have done seems fine. You can also assert not null if the instance variable can never be null.

I would consider testing setters/getters only if there is some non-trivial logic in there. — slnowak, Dec 16 '14 at 16:43

score 0 · Answer 2 · answered Dec 16 '14 at 16:49

Testing getters and setters could be a requirement in certain though rare scenarios where the container class is not just a POJO.

If that is a case,I would recommend creating a single TestSuite,dedicated to such instance variables,with each testcase's naming convention like :

TestGetVariableNameClassName
TestSetVariableNameClassName

You need to organize the test data such as maintenance is not tricky.

How do you do unit tests for getters and setters?

2 Answers2