I’ve spent the last few hours analyzing uses of @VisibleForTesting. Within the
first dozen or so I’ve discovered a few patterns.
@VisibleForTesting is a highly reliable indicator that:
1. The existence, name, and value/behavior of the annotated element are
implementation details and not requ
For constructors, I suggest that we don't need to use either annotation. A
package-private constructor that accepts parameters for all dependencies is
not breaking encapsulation or exposing internals and is very appropriate
for constructor based injection. It adheres to best practices as set out
fo
@VisibileForTesting is bad. It does NOT tell you if the method SHOULD HAVE
BEEN private, or package-private, or protected, so there is no way to
reconstruct the originally-intended code if the annotation is ever removed. It
also prevents the exposed methods from being named in a way that clear
I'm ok with not using these annotations, but we still need to write *unit
tests* in addition to end-to-end *system tests*.
I started this thread primarily to standardize on how we use one or both
annotations. We shouldn't be using both arbitrarily without some sort of
guidelines.
If we want to ac
Rather than change an in-production class scope for testing reasons, I would
like to see a new pass-through method with required scope and the @TestOnly
annotation. This leaves the in-use method alone with correct
encapsulation/visibility, and makes a clear, concise way to access it for test
th
I generally see @VisibleForTesting used to change permissions of a private
method, which is inaccessible to an external object, into a public method to
allow a test to reach in and set or get fields within a class.
I see it as an invaluable bridge between the reality of where we are now with
ou
Kirk and I often use @VisibleForTesting as part of a technique for making
complex code more testable.
Many classes have “hidden” dependencies that make that class hard to test. A
useful technique is to add a constructor parameter to allow a test to inject a
more controllable, more observable in
+1 to Donal.
And it also provides a way to easily find these places in the future that can
have some further refactoring. Just search for @VisibleForTesting and refactor
it away.
From: Donal Evans
Sent: Friday, November 5, 2021 9:19 AM
To: dev@geode.apache.org
The main time I use the @VisibleForTesting annotation is when I'm unit testing
a method that includes static calls that can't be mocked or verified. A random
example from the codebase is LatestLastAccessTimeMessage.process() which has a
call to sendReply(dm, lastAccessed) as the last line of the
