17

All of us have some utility classes, which contain only static methods, for usage from different sources. Now, there can be two approaches which can be taken towards testing this piece of code.

Approach 1:

Have separate unit tests for utility classes. Wherever they are being called, mock out their interaction using some test framework which has provision for it, such as PowerMock. This essentially treats the utility class as a separate component of the system, which needs to be individually tested out and maintained.

Approach 2:

Do not write unit tests for utility classes. However, tests which are written for your other core classes which interact with this utility class, let that interaction happen, which will intrinsically ensure that the code written in this utility class is properly tested for different usecases. If something breaks, the tests for other components should be able to catch it.

Please share your thoughts on which approach is preferable, or if there is some other manner in which people go about this.

Improve this question
1
  • 1
    Related: Static services and testability: “If a function is pure, then you can just test it directly once, and then use it in other code knowing that it will work. This usually only applies to small utility methods, or when you're doing strict functional programming. If the service provided by that static method is more complex, using dependency injection techniques becomes desirable.” In any case direct tests of public static methods make sense.
    – amon
    Dec 16, 2016 at 12:43

2 Answers 2

Reset to default
10

I think there is a big misunderstanding about 'utility' classes out there. Just because you make a class 'static' it does not make it a utility class. If your static utility class has dependencies (which may manifest themselves in other static 'utility' classes), it introduces side effects or its behavior cannot be completely controlled by its inputs is not a utility class.

True utility classes do not need to be mocked because their output is always deterministic depending on their inputs.

Unit testing is about instantiating a small part of your application (a unit) in isolation so you can (potentially) test all code paths within that unit. Mocking dependencies achieves this isolation. If a utility class breaks the isolation, again it is not a utility class because a utility class is supposed to be isolated by definition.

So in an application one should never want to or have to mock utility classes. Classes that you feel need to be mocked need to be turned into first class instantiable classes and need to be passed into the unit as a dependency (See Dependency Injection). These dependencies then can be mocked easily so the unit can be tested in isolation.

Improve this answer
20

In my opition it's ridiculous to mock out a dependency on a static utility method for things such as string splitting.

Yes, if the splitter method is wrong it might cause spurious failures in tests for methods that aren't about string splitting. But that's not the point of a test suite. The test suite must succeed 100%, period. If it doesn't, you fix what's broken and repeat until it succeeds 100%. If the string utility class gets broken, it should immediately cause a failure in a test that is about string functionality. You fix that functionality and then all failures disappear, so you never even have to look at the spuriously failing test cases.

In other words, YES, write tests for utility methods. NO, don't try to decouple them from other tests. Simply assume that trivial utility functions work correctly, as verified by their own tests. Doing anything more is more effort for no gain whatsoever.

Improve this answer
3
  • 1
    Just to be sure, you're preferring approach 2 over 1, right?
    – Ahmad Fadli
    Jun 22, 2018 at 6:57
  • 1
    @AhmadFadli No, he's saying that approach 3 is the best: Write tests for utility functions and don't mock them in other tests.
    – FINDarkside
    Feb 22, 2019 at 12:16
  • @AhmadFadli, "In other words, YES, write tests for utility methods. NO, don't try to decouple them from other tests" that means option second 2, I guess. Namely, write a test that utilizes Utility class methods but doesn't write tests insolation specific to a Utility method
    – Farid
    Oct 7, 2019 at 2:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.