How to Write Unit Test for a Setter Method Which Does Not Have a Getter Method

How to unit test setters on classes that do not have paired getters?

The problem here is that your don't want to change your API for your unit tests. Start looking at your unit tests as another user/consumer of your API. Just like developers using that library, unit tests have their own set of requirements. When you see your unit tests as consumer of your API, there will be a user that uses those getters, and it will justify them.

When this is not possible to change your API (for instance if you're developing an reusable framework), make the unit testing API internal and use the InternalsVisibleToAttribute to allow your testing library to access internal methods of your code.

Leaving unit tests aside, you still might want to consider having getters on those properties, because having properties without getters is very unintuitive for developers. The Framework Design Guidelines even have a rule against this:

DO NOT provide set-only properties or
properties with the setter having
broader accessibility than the getter.

You might also want to take that into consideration.

Good luck.

JUnit test for setter method

Here is your test:

@Test
  public void testSetDescription() {
    Room instance = new Room("test");
    instance.setDescription("abc\n");
    assertEquals("abc*", instance.getDescription());
  }

The assertEquals method is oveloaded and can be used in many ways. In this case we set in first place the expectation an on the second place what we really have (actual data) from the object. But in real life, most useful test is a test which check only single method, but in your case you call for one method but actually test other method. In real project you shouldn't test getters and setters. Only business logic, because if you'll test each method you will newer have time for main code.

Is it possible to unit test a method which have setter and getter using mockito and powermock

The problem is that your stub State object doesn't know that the value returned by getValue() should be the last value that was passed to setValue().

The stub created by Mockito doesn't automatically pick up that you have a getter and setter and the getter should return what the setter was last called with. It's just a dumb stub that only does what you've told it to do, and you haven't told it to do anything when setValue() is called.

It may be simplest to verify that setValue was called with the rounded value, rather than attempt to fetch it from getValue():

    Mockito.verify(context.getState()).setValue(AdditionalMatchers.eq(4.123, 0.0));

Another approach is to create a test State class that has real getters and setters, and use that in your tests. Of course, whether or not you can do this depends on how many other methods this class has. If you were to write such a class (I named it TestState in the code below), the test code would look like the following:

@Test
public void testProcess2(){
    Context context = Mockito.mock(Context.class);
    Mockito.when(context.getState()).thenReturn(new TestState());
    context.getState().setValue(4.12345);
    sample.process(context);
    assertEquals(4.123,context.getState().getValue(),0.0);
}

Should unit tests be written for getter and setters?

I would say no.

@Will said you should aim for 100% code coverage, but in my opinion that's a dangerous distraction. You can write unit tests that have 100% coverage, and yet test absolutely nothing.

Unit tests are there to test the behaviour of your code, in an expressive and meaningful way, and getters/setters are only a means to an end. If you tests use the getters/setters to achieve their goal of testing the "real" functionality, then that's good enough.

If, on the other hand, your getters and setters do more than just get and set (i.e. they're properly complex methods), then yes, they should be tested. But don't write a unit test case just to test a getter or setters, that's a waste of time.

PHPUnit Exclude Getters & setters

It really depends on what you have in those setters and getters but, to me, it really makes sense to test them even if they are as simple as setting a private/protected property.

Your program has an expected/desired behaviour given a certain input and unit tests make sure that there will be no regression issues.

For example, given a class with concrete setters/getters, you will be tempted to copy paste some of the methods and you might just forget to change the property name in one of the setters ending with 2 different setters for the same value:

class User 
{
    private $firstName;
    private $lastName;

    public function setFirstName($value) 
    {
        $this->firstName = $value;
    }

    public function getFirstName() 
    {
        return $this->firstName;
    }

    public function setLastName($value) 
    {
        $this->firstName = $value;
    }

    public function getLastName() 
    {
        return $this->lastName;
    }
}

and your test could be something like

public function testSetLastName_validValue_successful() 
{
    $user = new User;
    $value = 'Doe';
    $user->setLastName($value);
    $this->assertEquals($value, $user->getLastName());
}

This will immediately show the error in setLastName and it's a nice example of how TDD helps :)

Writing a few very simple unit tests for each setter/getter pair would save you from some annoyance.

Even When using overloading, unit tests are useful to ensure the domain of the magic setters/getters.

As for 'how to skip all getters and setters' ... just don't write tests for them ?

How do you do unit tests for getters and setters?

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.

How to test a class only with public getters and private setters with JUnit?

Your example code is a good example of code not written to enable easy unit testing. If you adopt the mindset that you have to design/structure/write your code in a way that makes it easier for you to test, then you shouldn't have these questions. Short answer, yes, expose setters as public to enable your testing, or package/default scope if you don't want the setters part of the public api.

Alternatively, you could add another constructor with parameters to set the values for you when you create an instance.

---

Related Topics