Primitive unit-tests

Question

Hello!

Is it worth to write unit-tests for such the simple code:

public class TableController {
  private TableView view;

  public TableController(TableView view) {
    this.view = view;
  }

  public void onShowTable() {
    view.showTable();
  }
}

I have a lot of such very simple code in my projects which connects controllers, views, services, remote services, etc. Unit-tests just repeat everything and are usually larger than the code itself:

public class TableControllerTest {
  @Test
  public void showTable() {
    TableView view = createMock(TableView.class);
    view.showTable();

    replayAll();

    TableController controller = new TableController(view);
    controller.onShowTable();

    verifyAll();
  }
}

Are such tests really needed?

Thanks!

Answer 1

Different people will have different opinions. You definitely need to test everything that could go wrong. What that means for you depends on you. Excessive testing can slow productivity just as too little testing can miss problems. You need to determine what works for you.

Answer 2

They are needed for when you change your method's implementation and need to ensure it still works. And when it happens 2 years later, it's too late to try to remember how the method worked to write a unit test - you should do it NOW.

They are less needed when you compare them to tests on more complicated methods/logic, but needed nonetheless.

Answer 3

Tests are always a good thing especially if you expect your code to grow over time. It's useful to be able to check if older functionality is still working fine after you refactor or make major changes to your code base.

In your specific case though, I think the functionality of these bits of code is too small to benefit from tests and tests that exercise showTable etc. would be more useful.

Answer 4

No. You don't have to unit test everything. On the other hand, you might want to try reversing the process and writing the tests first, then the code. In many cases you will find that if you write the test first, you end up writing different code that you thought you would as you're thinking about it from the perspective of what should be the outcome when you write the test rather than what code should I write. When writing tests in this fashion you'll find that the tests have much more value than simply exercising the code with them. Once you get the hang of it, you'll also get a feel for when you need the test and when you don't -- automatic property accessors, for instance, don't need to be unit tested IMO.

If you're already doing the tests first, then I'm not sure I understand the question since your tests can't repeat something that hasn't been written yet. You've used your tests to define what the methods should do. That's a very useful activity and also protective in the event that other tests cause a breaking change. Much better to find it in a unit test than in a live application.

Answer 5

I wouldn't test simple delegating methods.

There is nice saying (though I cannot remember who it was coming from): "Never test stuff which is too simple to break..."

Answer 6

code in my projects which connects controllers, views, services, remote services, etc.

For that kind of thing, unit tests are probably not useful - but integration tests are, i.e. tests that check that the functionality of the application as a whole (probably on a use case basis) with a minimum of mocking. These take longer and can't run through all the edge cases, but they're very valuable in revealing problems in the way components interact - and in this kind of glue code.

Answer 7

Tests for modules like that aren't really needed. However, tests for modules like that aren't hard to write. So there's really no harm in writing the tests. You also have to remember that simple modules of the kind you've shown tend to grow over time. If you don't have a test for the module, then when a new bit of logic is added to the module, you may decide that the delta between the old module and the new logic is too simple to test. Bit by bit the module grows without being tested.

So in the end, I will write the tests even for simple modules since they are simple to write, and they act as place holders for when the modules become more complicated.