You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <p....@ubik-ingenierie.com> on 2016/11/27 21:18:52 UTC
deprecated public default constructors in code for Unit testing
Hello,
Looking for Deprecated code in JMeter to make some cleanup, I noticed that
we have a lot of classes with default Constructors marked as Deprecated for
Unit Test only.
Couldn't we find a better way to do that and avoid using deprecated for
that ?
--
Regards.
Philippe
Re: deprecated public default constructors in code for Unit testing
Posted by sebb <se...@gmail.com>.
On 4 December 2016 at 14:31, Philippe Mouawad
<ph...@gmail.com> wrote:
> On Sun, Dec 4, 2016 at 3:25 PM, sebb <se...@gmail.com> wrote:
>
>> On 4 December 2016 at 14:13, Felix Schumacher
>> <fe...@internetallee.de> wrote:
>> > Am 27.11.2016 um 23:05 schrieb sebb:
>> >>
>> >> On 27 November 2016 at 21:18, Philippe Mouawad
>> >> <p....@ubik-ingenierie.com> wrote:
>> >>>
>> >>> Hello,
>> >>> Looking for Deprecated code in JMeter to make some cleanup, I noticed
>> >>> that
>> >>> we have a lot of classes with default Constructors marked as Deprecated
>> >>> for
>> >>> Unit Test only.
>> >>>
>> >>> Couldn't we find a better way to do that and avoid using deprecated for
>> >>> that ?
>> >>
>> >> What's wrong with using deprecated?
>> >>
>> >> The advantage is that it's immediately obvious in main code.
>> >> Test code often needs to continue to test deprecated methods, so it's
>> >> OK to suppress deprecated warnings.
>> >> Whereas it's (almost) never right to suppress a deprecation warning in
>> >> main code.
>> >
>> > I think one of the unit tests uses reflection to find default
>> constructors
>> > or constructors with object as an argument. It searches for those
>> > constructors on all Serializable classes it finds (at least it looked
>> like
>> > that), which seems a bit strange to me. This test emits a warning, when
>> it
>> > can't find one of those classes (as is the case with
>> > o.a.j.protocol.http.parser.CSSParseExceptionCallback which I refused to
>> give
>> > a default constructor, as it would not be able to set a valid baseUrl).
>> > I think we should limit the classes to test to something meaningful, or
>> at
>> > least give a list of exceptions, where the missing constructors are no
>> > problem.
>>
>> That's a slightly separate issue.
>> If we don't need the ctor for testing, then obviously the deprecated
>> tag is not needed.
>> However if the ctor is needed for testing, then I think the
>> @deprecated approach is a good way to try and prevent its use in
>> normal code.
>>
>
> IMO, deprecated means "replaced by something else and to be removed".
> Another annotation should be available if no better way is found.
To me it can also mean - it is available, but should not be used
unless absolutely necessary.
> Not fully related to this particular issue but with unit tests in general,
> maybe we should investigate introducing Mockito 2:
> https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2
Please start a new thread for a new subject.
>>
>> > Regards,
>> > Felix
>> >
>> >>
>> >>> --
>> >>> Regards.
>> >>> Philippe
>> >
>> >
>> >
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: deprecated public default constructors in code for Unit testing
Posted by Philippe Mouawad <ph...@gmail.com>.
On Sun, Dec 4, 2016 at 3:25 PM, sebb <se...@gmail.com> wrote:
> On 4 December 2016 at 14:13, Felix Schumacher
> <fe...@internetallee.de> wrote:
> > Am 27.11.2016 um 23:05 schrieb sebb:
> >>
> >> On 27 November 2016 at 21:18, Philippe Mouawad
> >> <p....@ubik-ingenierie.com> wrote:
> >>>
> >>> Hello,
> >>> Looking for Deprecated code in JMeter to make some cleanup, I noticed
> >>> that
> >>> we have a lot of classes with default Constructors marked as Deprecated
> >>> for
> >>> Unit Test only.
> >>>
> >>> Couldn't we find a better way to do that and avoid using deprecated for
> >>> that ?
> >>
> >> What's wrong with using deprecated?
> >>
> >> The advantage is that it's immediately obvious in main code.
> >> Test code often needs to continue to test deprecated methods, so it's
> >> OK to suppress deprecated warnings.
> >> Whereas it's (almost) never right to suppress a deprecation warning in
> >> main code.
> >
> > I think one of the unit tests uses reflection to find default
> constructors
> > or constructors with object as an argument. It searches for those
> > constructors on all Serializable classes it finds (at least it looked
> like
> > that), which seems a bit strange to me. This test emits a warning, when
> it
> > can't find one of those classes (as is the case with
> > o.a.j.protocol.http.parser.CSSParseExceptionCallback which I refused to
> give
> > a default constructor, as it would not be able to set a valid baseUrl).
> > I think we should limit the classes to test to something meaningful, or
> at
> > least give a list of exceptions, where the missing constructors are no
> > problem.
>
> That's a slightly separate issue.
> If we don't need the ctor for testing, then obviously the deprecated
> tag is not needed.
> However if the ctor is needed for testing, then I think the
> @deprecated approach is a good way to try and prevent its use in
> normal code.
>
IMO, deprecated means "replaced by something else and to be removed".
Another annotation should be available if no better way is found.
Not fully related to this particular issue but with unit tests in general,
maybe we should investigate introducing Mockito 2:
https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2
>
> > Regards,
> > Felix
> >
> >>
> >>> --
> >>> Regards.
> >>> Philippe
> >
> >
> >
>
--
Cordialement.
Philippe Mouawad.
Re: deprecated public default constructors in code for Unit testing
Posted by sebb <se...@gmail.com>.
On 4 December 2016 at 14:13, Felix Schumacher
<fe...@internetallee.de> wrote:
> Am 27.11.2016 um 23:05 schrieb sebb:
>>
>> On 27 November 2016 at 21:18, Philippe Mouawad
>> <p....@ubik-ingenierie.com> wrote:
>>>
>>> Hello,
>>> Looking for Deprecated code in JMeter to make some cleanup, I noticed
>>> that
>>> we have a lot of classes with default Constructors marked as Deprecated
>>> for
>>> Unit Test only.
>>>
>>> Couldn't we find a better way to do that and avoid using deprecated for
>>> that ?
>>
>> What's wrong with using deprecated?
>>
>> The advantage is that it's immediately obvious in main code.
>> Test code often needs to continue to test deprecated methods, so it's
>> OK to suppress deprecated warnings.
>> Whereas it's (almost) never right to suppress a deprecation warning in
>> main code.
>
> I think one of the unit tests uses reflection to find default constructors
> or constructors with object as an argument. It searches for those
> constructors on all Serializable classes it finds (at least it looked like
> that), which seems a bit strange to me. This test emits a warning, when it
> can't find one of those classes (as is the case with
> o.a.j.protocol.http.parser.CSSParseExceptionCallback which I refused to give
> a default constructor, as it would not be able to set a valid baseUrl).
> I think we should limit the classes to test to something meaningful, or at
> least give a list of exceptions, where the missing constructors are no
> problem.
That's a slightly separate issue.
If we don't need the ctor for testing, then obviously the deprecated
tag is not needed.
However if the ctor is needed for testing, then I think the
@deprecated approach is a good way to try and prevent its use in
normal code.
> Regards,
> Felix
>
>>
>>> --
>>> Regards.
>>> Philippe
>
>
>
Re: deprecated public default constructors in code for Unit testing
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 27.11.2016 um 23:05 schrieb sebb:
> On 27 November 2016 at 21:18, Philippe Mouawad
> <p....@ubik-ingenierie.com> wrote:
>> Hello,
>> Looking for Deprecated code in JMeter to make some cleanup, I noticed that
>> we have a lot of classes with default Constructors marked as Deprecated for
>> Unit Test only.
>>
>> Couldn't we find a better way to do that and avoid using deprecated for
>> that ?
> What's wrong with using deprecated?
>
> The advantage is that it's immediately obvious in main code.
> Test code often needs to continue to test deprecated methods, so it's
> OK to suppress deprecated warnings.
> Whereas it's (almost) never right to suppress a deprecation warning in
> main code.
I think one of the unit tests uses reflection to find default
constructors or constructors with object as an argument. It searches for
those constructors on all Serializable classes it finds (at least it
looked like that), which seems a bit strange to me. This test emits a
warning, when it can't find one of those classes (as is the case with
o.a.j.protocol.http.parser.CSSParseExceptionCallback which I refused to
give a default constructor, as it would not be able to set a valid baseUrl).
I think we should limit the classes to test to something meaningful, or
at least give a list of exceptions, where the missing constructors are
no problem.
Regards,
Felix
>
>> --
>> Regards.
>> Philippe
Re: deprecated public default constructors in code for Unit testing
Posted by sebb <se...@gmail.com>.
On 27 November 2016 at 21:18, Philippe Mouawad
<p....@ubik-ingenierie.com> wrote:
> Hello,
> Looking for Deprecated code in JMeter to make some cleanup, I noticed that
> we have a lot of classes with default Constructors marked as Deprecated for
> Unit Test only.
>
> Couldn't we find a better way to do that and avoid using deprecated for
> that ?
What's wrong with using deprecated?
The advantage is that it's immediately obvious in main code.
Test code often needs to continue to test deprecated methods, so it's
OK to suppress deprecated warnings.
Whereas it's (almost) never right to suppress a deprecation warning in
main code.
> --
> Regards.
> Philippe