Ah, I see. Thanks for answering my questions Martin. Sounds like there's no real benefit then to using guava-testlib in this changeset instead of CollectionTest. And even if the benefit of using it was considered to be high enough in the future, it would probably need its own JSR, since I presume it would be applicable to a number of places in the jdk, making it a humongous change.
Overall, it seems sensible to wait until e.g. JUnit 5 develops a worthwhile solution to the dynamic test generation problem, at which point we could then consider it for writing exhaustive tests for the jdk collections. Thanks again, Jonathan On 20 October 2016 at 04:45, Martin Buchholz <marti...@google.com> wrote: > > > On Wed, Oct 19, 2016 at 4:40 PM, Jonathan Bluett-Duncan < > jbluettdun...@gmail.com> wrote: > >> Hi Martin, >> >> By collections infrastructure, do you mean something like the collection >> testers in guava-testlib? >> >> If so, I agree that JUnit 5's dynamic tests look promising for >> implementing such an infrastructure. I admit I don't have all the context >> here, but would using guava-testlib in the meantime be a viable medium- or >> short-term solution? Or would its dependence on JUnit 3/4 make switching >> impractical? Or, perhaps, has development into CollectionTest gone so far >> that, for that reason instead, it would be impractical until switch, at >> least until something superior using e.g. JUnit 5's dynamic tests is made? >> > > I'm embarrassed to say I'm not familiar enough with guava's testlib. > Guava does have generic collection oriented tests, and even runs them on > jdk classes. (Someone on the jdk quality team should be running the guava > tests using development jdks!). I'm not familiar enough with the tools to > work on this myself, but I encourage someone who is to do that. > > I see that guava testlib does have: > > TestsForQueuesInJavaUtil.java > TestsForSetsInJavaUtil.java > TestsForListsInJavaUtil.java > TestsForMapsInJavaUtil.java > > and that the infrastructure there is vaguely similar to what I ended up > doing. JDK version skew is a problem, because openjdk development is > focused on jdk9, while guava is still trying to digest jdk8. >
