Introduce JUnit Jupiter variant of Guava's collection test suite builders

Hi all at junit-pioneer!

Three years ago, I opened an issue where I offered to contribute an extension for testing Java collections similar to Guava’s collection suite builders (CSBs), which @nipafx expressed an interest in. In the end I took my offer back because I developed some work independently, which I wanted to keep independent because of the amount of work I put into it and so that I could experiment with some static analysis tools.

However, I was relatively inexperienced, and I tried to build a CSB for List first, which turned out to be a poor idea because it was one of the larger interfaces in the collections framework. Furthermore I had just started a full-time role at Argos, a UK retailer, so my free time was reduced and I abandoned the project.

I’m now at a point where I want to try writing some CSBs again, so I wanted to ask if you’d be interested in hosting this work again.

What do you think? @nipafx, would you still be interested in this?

[jbduncan]

@Michael1993 Thanks for labelling this issue (even though it’s still “in discussion”) and for assigning me!

[jbduncan]

Thanks for your thoughts on this, @nipafx. 😁

Good point about (2) not supporting JUnit 4 extensions, I hasn’t considered that. So I agree, let’s consider other options first.

Two ideas for approaching (1) come to mind. What do you think, team?

1. Make a builder of DynamicTests for @TestFactory methods.
   1. Pros:
      1. It mimics guava-testlib’s approach, which I think is beautiful.
      2. It lets users to test any number of iterables at runtime, allowing them to be loaded from e.g. a ServiceLoader or Spring.
   2. Cons:
      1. No built-in support for lifecycle stages like “before each”, which is something that guava-testlib’s own builders expose to users, so supporting this would be extra work. We could see how guava-testlib does this.
      2. If a user forgets to pass in the iterable under test, it would fail at runtime rather than compile time. (Then again, tests are meant to fail at runtime anyway…)
2. Put the tests in an interface for test classes to extend.
   1. Pros:
      1. This is a supported idea in JUnit Jupiter.
      2. It allows users to use lifecycle methods easily with no extra work.
      3. It can enforce that an iterable is passed in at compile time.
   2. Cons:
      1. Some people prefer other approaches to extending interfaces/classes for sharing common tests, or they wish that such other approaches existed.
      2. It can only support a fixed number of iterables, as they have to be hardcoded into an equal number of test classes. (Then again, how many people need this flexibility? Even with something like Spring, users are most likely to have a fixed number of custom collections anyway. What about a ServiceLoader, how common is that for loading collections? Furthermore, how many frameworks create collections at build time or runtime with a tool like JavaPoet or Byte Buddy, anyway?)