Is it necessary to test each method individually?

Question

I am writing Unit tests for my controller methods and many of the methods call on other methods which then also calls on other methods until finally returning a result. Now from what I have read on best practices one should test each method even if it has been essentially "tested" through another method.

To put this in perspective lets say I have these 3 methods and I do an assertTrue(MethodA) is it really necessary that I test MethodB and then MethodC as well? If so why?

  public Boolean MethodA(Object o)
    {
        try {
            //Do stuff
            return MethodB(Object o);
        }
        catch(Exception e)
        {
            return false;
        }
    }

    public Boolean MethodB(Object o)
    {
        try {
            //Do stuff
            return MethodC(Object o);
        }
        catch(Exception e)
        {
            return false;
        }
    }

    public Boolean MethodC(Object o)
    {
        try {
            //Do stuff with o
            //return True
        }
        catch(Exception e)
        {
            return false;
        }
    }

I would test them individually, because all methods are public and the cascading calls are an implementation detail — Meini, Nov 26 '18 at 12:37
The methods are public, there's no guarantee that `methodA` is the only caller of `methodB` and `methodC`, so if they are not tested, other callers may break when they change. — daniu, Nov 26 '18 at 12:49

Roland · Accepted Answer · 2018-11-26T12:44:54.747

It depends on you and your team actually. In this case I would probably test them all.

One reason being: how else could I ensure that when methodA() returned false that it is due to the calculation that was done in methodB() or an exception from there? Same question applies to methodC() as well... if there is thrown an exception we get false, but how should I know whether (actually: ensure that) it was due to an exception or from an actual calculation?

If you would test that through methodA() only that test alone will probably become way too complex and you would add too much logic of the inner workings to that specific test(s). Try to test/challenge your method from an outside view. Everything that is visible from outside you probably want to test alone. Also: keep your tests simple enough that when you return you can easily grasp why you tested it this way.

score 2 · Answer 2 · answered Nov 26 '18 at 12:38

Yes, you should test them all. At some point in the future the implementation of one of the calling methods, say MethodA, may change and you need to test if all the old uses are still applicable. There are several points I would considered in this situation:

Is it really necessary to have all this methods just calling another method that is calling another method, etc? I mean, if all methods are public, why should an external object call MethodA and not directly MethodC? I'm not saying you must eliminate all internal call, but a public method should expose a unique functionality, and each functionality should be available only through one method.
Could you make some of the methods private? if you have this kind of nested calls to reuse code, you should encapsulate the called methods by avoiding external objects to call them, because they are effectively implementation detail, and not part of the exposed functionalities.

score 2 · Answer 3 · answered Nov 26 '18 at 12:40

Look at this Question How to best test Java code?. There are some good advices on how to test and how much of your code you need to test (Answer https://stackoverflow.com/a/1139266/10606957 explaines the 80:20 approach in programming). Even if those answers aim at some bigger projects, it might be good to learn those things from scratch.

NOTE: Would have made this a comment but I haven´t unlocked comments jet ^^

Is it necessary to test each method individually?

3 Answers3