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. HTH, Gary > wdyt? > > Phil >
