7

I'm aware that there are many questions about mocking and testing, but I didn't find any that helped me perfectly, so I still have problems understanding the follwing:

Please correct me if I got this wrong, but as far as I see, unit tests are used to test the business logic of one particular class in isolation and if there are any objects needed from the outside they will be mocked. So for example if I have a management system for citizens of a simple city that adds citizens to a list and returns the citizen by their names (Assumtion: citizens consist of only a few basic personal information), like this:

public class ProcessClass {

    ArrayList<Citizen> citizenList = new ArrayList<Citizen>();

    public void addCitizen(Citizen citizen) {
        citizenList.add(citizen);
    }

    public Citizen getByName(String name) {
        for (Citizen c : citizenList) {
            if (c.getName().equals(name)) {
                return c;
            }
        }
        return null;
    }

}

If now I want to unit test my ProcessClass do I consider Citizen as an external feature that has to be mocked, or do I simply just create a Citizen for test purposes? If they are mocked, how would I test the method to get the object by its name, since the mock object is not containing the parameters?

jle
  • 686
  • 1
  • 8
  • 24
  • 2
    If you are writing `TestProcessClass`, you should not mock `ProcessClass` since it is what you are testing. I assume in this case `Citizen` is a data class with no logic so there is no point in mocking it. However, if you use another class with logic, consider mocking it – DanielM May 10 '19 at 12:58
  • it really depend on what you are trying to test. If you are trying to test the `addCitizen` method, you don't need to create a mock citizen object. But if you are trying to test the `getByName` method, I would say you could create a mock Citizen with a name and assign it to your ProcessClass, then test the `getByName`. Mock are moslty used whit services. For example, if you want to test a class that access a database without an actual databases. – Nicolas May 10 '19 at 12:58
  • 3
    If `Citizen` is just a simple data class I would just create them. Generally, it's best to avoid mocking if you can. Mocking is useful for services and dependencies. – Boris the Spider May 10 '19 at 12:59
  • Okay that's kind of implicated to the question: since Citizen doesn't contain any logic can it be used in the ProcessClassTest or would it be a violation of the isolation to include these kind of non-logical classes as they are? – jle May 10 '19 at 13:03

5 Answers5

6

As you're writing new code (along with the new unit tests) or refactoring existing code, you want to be able to run the unit tests over and over to be reasonably confident existing functionality was not broken. Therefore, the unit tests must be stable and fast.

Suppose the class to be tested depends on some external resource such as a database. You make a code change and the unit tests are suddenly failing. Did the unit tests break because of a bug you just introduced, or because the external resource is not available? There is no guarantee the external resource will always be available so the unit tests are unstable. Mock the external resource.

Also, connecting to an external resource can take too much time. When you eventually have thousands of tests which connect to various external resources, the milliseconds to connect to the external resource add up, which slows you down. Mock the external resource.

Now add a CI/CD pipeline. During the build the unit tests fail. Is the external resource down or did your code change break something? Perhaps the build server doesn't have access to an external resource? Mock the external resource.

Andrew S
  • 2,509
  • 1
  • 12
  • 14
6

To answer the first part of your question

If now I want to unit test my ProcessClass do I consider Citizen as an external feature that has to be mocked, or do I simply just create a Citizen for test purposes?

Without knowing more about Citizen it is hard to tell. However, the general rule is, that mocking should be done for a reason. Good reasons are:

  • You can not easily make the depended-on-component (DOC) behave as intended for your tests.
  • Does calling the DOC cause any non-derministic behaviour (date/time, randomness, network connections)?
  • The test setup is overly complex and/or maintenance intensive (like, need for external files)
  • The original DOC brings portability problems for your test code.
  • Does using the original DOC cause unnacceptably long build / execution times?
  • Has the DOC stability (maturity) issues that make the tests unreliable, or, worse, is the DOC not even available yet?

For example, you (typically) don't mock standard library math functions like sin or cos, because they don't have any of the abovementioned problems. In your case, you need to judge whether just using Citizen would cause any of the abovementioned problems. If so, it is very likely better to mock it, otherwise you better do not mock.

Dirk Herrmann
  • 5,550
  • 1
  • 21
  • 47
3

More often than not, mocking is used to replace actual calls that are hard to duplicate in testing. For instance, assume ProcessClass makes a REST call to retrieve Citizen information. For a simple unit test, it would be hard to duplicate this REST call. However, you can "mock" the RestTemplate and dictate the different types of returns to insure your code would handle the 200's, 403's, etc. Additionally you could change the type of information to then also test your code to insure that bad data is handled, like missing or null information.

In your case you can actually create a Citizen, and then test that the Citizen is an object in the list or that getByName returns the proper object. So mocking is not needed in this example.

JavaJd
  • 445
  • 1
  • 7
  • 17
  • 1
    Additionally, I find Baeldung to be helpful more times than not, here is a list of their articles on testing --> https://www.baeldung.com/junit as well as one on Mockito --> https://www.baeldung.com/mockito-series. Cheers! – JavaJd May 10 '19 at 13:07
3

In your particular example, no, you would not need to mock anything.

Let's focus on what you would test:

  1. a test where you add and retrieve one Citizen
  2. add 2 Citizens, retrieve one
  3. pass null instead of citizen, and make sure your code doesn't break.
  4. add two citizens with the same name, what would you expect to happen then?
  5. add a citizen without a name.
  6. add a citizen with a null name

etc etc

You can already see a number of different tests you can write.

To make it more interesting you could add some code to your class which exposes a read-only version of your citizenList, then you could check that your list contains exactly the right things.

So, in your scenario you don't need to mock anything as you don't have external dependencies on another system of some kind. Citizen seems to be a simple model class, nothing more.

Andrei Dragotoniu
  • 6,155
  • 3
  • 18
  • 32
2

If they are mocked, how would I test the method to get the object by its name, since the mock object is not containing the parameters?

You can mock the call to getName, using mockito for example: 

Citizen citizen = mock(Citizen.class);
when(citizen.getName()).thenReturn("Bob");

Here is an example of a test for your method

ProcessClass processClass = new ProcessClass();

Citizen citizen1 = mock(Citizen.class);
Citizen citizen2 = mock(Citizen.class);
Citizen citizen3 = mock(Citizen.class);

@Test
public void getByName_shouldReturnCorrectCitizen_whenPresentInList() {
    when(citizen1.getName()).thenReturn("Bob");
    when(citizen2.getName()).thenReturn("Alice");
    when(citizen3.getName()).thenReturn("John");

    processClass.addCitizen(citizen1);
    processClass.addCitizen(citizen2);
    processClass.addCitizen(citizen3);

    Assert.assertEquals(citizen2, processClass.getByName("Alice"));
}

@Test
public void getByName_shouldReturnNull_whenNotPresentInList() {
    when(citizen1.getName()).thenReturn("Bob");

    processClass.addCitizen(citizen1);

    Assert.assertNull(processClass.getByName("Ben"));
}

Note:

I would recommend mocking. Let's say you write 100 tests where you instantiate a Citizen class this way

Citizen c = new Citizen();

and a few months later, your constructor changes to take an argument, which is an object itself, class City for example. Now you have to go back and change all these tests and write:

City city = new City("Paris");
Citizen c = new Citizen(city);

If you mocked Citizen to start with, you wouldn't need to.

Now, as it is POJO and its constructor of the getName method might not change, not mocking should still be ok.

Bentaye
  • 9,403
  • 5
  • 32
  • 45