Agreed, but the following (inside tests) does not work in all cases, i.e.
Region<String, String> region...
Particularly if "region" is passed to a method with a different type
signature.
I am trying to find/think of the situation I encounter from time to time,
even when I use the *wildcard* signature (i.e. Region<?, ?>), but cannot
currently find it (*#ugh*).
Anyway, the point is, if the test is really not concerned with the type of
values (*keys*, *values*) being stored in the mock *Region* then rawtypes (or
sometimes Region<?, ?>) are useful in some cases since the point of the
test is not about the data but perhaps about *Region* configuration in
general, so adding types detracts (adds undue noise) to the code under test
(IMO).
It depends and is subjective.
I agree, though, in general, @SuppressWarnings should be kept to a minimum
and used only when necessary.
-j
On Fri, May 8, 2020 at 1:09 PM Kirk Lund <kl...@apache.org> wrote:
> Actually there is an alternative to using @SuppressWarnings for Mockito
> mocks:
>
> Region<String, String> region = cast(mock(Region.class));
>
> private static <T> T cast(Object object) {
> return (T) object;
> }
>
> Personally, I'd prefer to see warnings or workarounds like above than see
> lots of @SuppressWarnings littered throughout our code base. I think it's a
> smell of bad code.
>
> On Fri, May 8, 2020 at 12:44 PM Jacob Barrett <jbarr...@pivotal.io> wrote:
>
> >
> >
> > > On May 8, 2020, at 12:41 PM, Donal Evans <doev...@pivotal.io> wrote:
> > >
> > > Is there a consensus on what constitutes a benign warning? I think the
> > only
> > > times I use @SuppressWarnings is in parameterized tests to suppress the
> > > unused method warning for the parameters method, or for unchecked
> casts,
> > as
> > > below:
> > >
> > > PartitionedRegion detailRegion1 = mock(PartitionedRegion.class);
> > > when(cache.getRegion(regionPath1)).thenReturn(detailRegion1);
> > >
> > > where the thenReturn() would complain, since it's expecting to return a
> > > Region<Object, Object>.
> > >
> > > Would these be considered things that could safely just be ignored (and
> > so
> > > for which I can turn off inspection), or is the use of
> @SuppressWarnings
> > > here warranted?
> >
> > This is a legitimate suppression. There is no other way to correct the
> > dysfunctional nature of Java Generics than to @SuppressWarnings. In this
> > case though only that statement should be suppressed.
> >
> > -Jake
> >
> >
>
--
-John
Spring Data Team
