> On May 24, 2025, at 5:53 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> On Sat, May 24, 2025, 20:22 Phil Steitz <p...@steitz.com> wrote:
>
>> The [pool] unit tests in the 2_X branch are riddled with deprecation
>> warnings mostly due to either changed method names or legacy time-related
>> methods where the non-deprecated version takes a Duration instead of a
>> long. I am on the fence as to whether to fix these now or wait until the
>> deprecated methods are deleted in the next major release. The reasons to
>> fix them now are
>>
>> 0) The unit tests are useful in learning how to do things. Having them full
>> of deprecations is not good for that purpose.
>>
>
> I disagree: the primary and most important role of this code is to test.
> This feels like more of a perhaps weakness in our Javadoc or site docs.
>
> Testing deprecated code is just as important as testing regular code.
>
> There are three audiences to teach, if we are going to overload the role of
> tests as a learning tool: end-users of the library, maintainers, and future
> contributors at large.
>
> Testing deprecated and regular code teaches maintainers and contributors
> best-practices in achieving higher code coverage. This, in turn, gives
> end-users a higher level of confidence in our code. This also gives us
> maintainers a higher level of confidence in making changes, knowing that
> regressions will be caught.
>
>
>> 1) Unless we duplicate them all, the current tests don't test the
>> non-deprecated versions.
>>
>> 2) The implementations of the long-based methods just delegate to the
>> non-deprecated versions, so there is no real loss in coverage by fixing the
>> deprecations
>>
>
>
> This is a hack IMO because it assumes internal knowledge and turns what are
> black box tests into whitebox tests. We don't cleanly distinguish this in
> tests because it doesn't seem worth it but I would not want to not test
> something because the code is implemented a certain way today.
>
> How to best organize testing of deprecated and regular code is a different
> topic from that main vein of this message so we could address it separately
> if needed.
Thanks, Gary. I will leave them as is.
Phil
>
> HTH,
> Gary
>
>
>> wdyt?
>>
>> Phil
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
