Additionally, it'd be ideal if the deprecated method were then adapted to
delegate to the new approach. This will cut down on the number of required
tests since then you only need a Unit Tests asserting the method performs
the translation/delegating appropriately, unless of course the behavior is
changing too.
On Tue, Mar 17, 2020 at 8:57 AM Udo Kohlmeyer <ukohlme...@pivotal.io> wrote:
> I think we are also missing the other side of the coin.
>
> Once we deprecate something and we now need a equivalent test that tests
> the same behavior using the new method/approach. i.e now we have to
> double up on the testing of said deprecated method/feature/class. First
> we have to keep the tests around that use the deprecated and now we need
> the same test for the new. Otherwise we cannot ever be certain that both
> approaches work.
>
> In addition to this, if we don't create both tests, we have to create
> all the tests at the time of removal, otherwise we lose coverage.
>
> --Udo
>
> On 3/16/20 9:27 AM, Joris Melchior wrote:
> > +1 on leaving testing of deprecated functionality in place
> >
> > On Mon, Mar 16, 2020 at 11:50 AM Dan Smith <dsm...@pivotal.io> wrote:
> >
> >> +1
> >>
> >> One point though - we do need to leave some tests that specifically test
> >> the deprecated method(s), since we still support the deprecated APIs
> until
> >> we remove them. Everything else should be converted.
> >>
> >> -Dan
> >>
> >> On Sun, Mar 15, 2020 at 6:41 PM Jacob Barrett <jbarr...@pivotal.io>
> wrote:
> >>
> >>> Hey Team,
> >>>
> >>> When deprecating a symbol, like class or method, please included a
> >>> reference to the replacement in the java docs. Also please include an
> >>> example of converting from the old API to the new. I am finding many
> many
> >>> places in the source where deprecated code has no hints at all. As many
> >> of
> >>> us don’t take the effort to immediately convert old tests over to the
> new
> >>> APIs the context is lost when someone finally does get around to it.
> For
> >>> public APIs this is extremely important so that users know how to
> migrate
> >>> their code with as few roadblocks as possible.
> >>>
> >>> Here is an example of something that is much better than most of what I
> >> am
> >>> seeing.
> >>>
> >>> /**
> >>> * @deprecated Replaced with something better and safer.
> >>> * Replaced by {@link Bar}.
> >>> */
> >>> @Deprecated
> >>> class Foo {
> >>> /**
> >>> * Do something.
> >>> *
> >>> * @deprecated Replaced with something better.
> >>> * Replaced by {@link Bar#doSomethingBetter()}
> >>> */
> >>> @Deprecated
> >>> public void doSomething() {}
> >>>
> >>> /**
> >>> * Do something.
> >>> *
> >>> * @deprecated Implementation is not safe.
> >>> * Replaced with {@link Bar#doSomethingBetter()} and {@link
> >>> Bar#doSomethingElse()}.
> >>> * Migration example, replace:
> >>> * <pre>{@code
> >>> * Foo foo = new Foo();
> >>> * foo.doSomethingAndSomethingElse();
> >>> * }</pre>
> >>> * with:
> >>> * <pre>{@code
> >>> * Bar bar = Bar();
> >>> * bar.doSomethingBetter();
> >>> * bar.doSomethingElse();
> >>> * }</pre>
> >>> */
> >>> @Deprecated
> >>> public void doSomethingAndSomethingElse() {}
> >>> }
> >>>
> >>> class Bar {
> >>> public void doSomethingBetter() {}
> >>> public void doSomethingElse() {}
> >>> }
> >>>
> >>> -Jake
> >>>
> >>>
> >
>
--
-John
Spring Data Team
