Refactor instance based utility classes to static utility classes
See original GitHub issueThe internal implementation of Mockito contains numerous helper classed that serve as a container for useful methods. By its nature these classes don’t have a state. Currently some them are instance based in other word you need to create the utility class to call a helper method. This not only pollutes the heap but also the code cause instance methods can’t be imported statically.
Here is an example:
Helper helper = new Helper();
if (helper.isInputValid(input)){
[...]
}
vs. static import of Helper.isInputValid
if (isInputValid(input)){
[...]
}
The aim of this ticket is to identify canidates that can be refactored to static utility classes. If you like to refactoring and mockito feel free to send a PR and reference this issue.
Refactoring canidates:
-
AccessibilityChanger
-
BeanPropertySetter
-
ConditionalStackTraceFilter
-
FieldCopier
-
FieldReader
-
GenericMaster
should be integrate intoGenericTypeResolver
-
JUnitFailureHacker
can be removed when the deprecatedVerboseMockitoJUnitRunner
is removed -
LenientCopyTool
-
MatcherBinder
-
MockitoCore
should better be a singleton -
MockCreationValidator
-
RemoveFirstLine
- #591
ArgumentMatchingTool
- #515
AllInvocationsFinder
- #502
ArgumentsComparator
- #540
ArrayUtils
- #490
AtLeastXNumberOfInvocationsChecker
- #490
AtLeastXNumberOfInvocationsInOrderChecker
- #912
Constructors
- #427
FieldSetter
- #908
FriendlyExceptionMaker
- #431
HandyReturnValues
- #432
InvocationMarker
- #462
InvocationsFinder
- #908
JUnitDetecter
- #490
MissingInvocationChecker
- #490
MissingInvocationInOrderChecker
- #514
MockUtil
- #503
NonGreedyNumberOfInvocationsInOrderChecker
- #907
NumberOfInvocationsInOrderChecker
- #907
NumberOfInvocationsChecker
- #547
ObjectMethodsGuru
- #427
Reporter
- #535
SuperTypesLastSorter
- #501
TestMethodFinder
- #515
VerifiableInvocationsFinder
Issue Analytics
- State:
- Created 7 years ago
- Comments:26 (24 by maintainers)
Top Results From Across the Web
What is the best way to refactor Utility class in java (static ...
Maybe an example would be useful. · Sometimes you want to mock them, they might be troublesome to do so. · can you...
Read more >3 Considerations for Your Next Utility Function Refactor - Innovid
The first option is a static function in a new class. The second option, assuming you use any dependency injection framework (e.g. Guice),...
Read more >Refactoring - Utility classes behavior under a common interface
it can have a private constructor and expose only static methods. Yes, it can, but there is no technical need for.
Read more >Refactoring - How to safely convert a static class with tons of ...
Many programmers are attracted towards the ease of programming and simplicity in writing static classes and methods to implement utility ...
Read more >OOP Alternative to Utility Classes - Yegor Bugayenko
A utility class (aka helper class) is a “structure” that has only static methods and encapsulates no state.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
To me it feels like unnecessary/duplicate code cause
this
is implicit. Addingthis.
before every instance call would create a lot more text and would IMHO reduce readability. E.g.:this.doSometing(this.withPrivateMethod())
vs.doSomething(withPrivateMethod())
An other option avoid ambiguity is to qualify static methods via its class name. This way you can also distinguish which verify(…) is called (
MockitoCore.verify(..)
/Mocktio.verify(..)
) , which is not an easy task when a static import is used.@TimvdLippe know what you mean! The next PR’s include only one refactored class at a time.