RFR: jsr166 jdk9 integration wave 12 (original) (raw)

Martin Buchholz martinrb at google.com
Fri Nov 18 18:16:36 UTC 2016

Regarding the testing mess:

I think there should be a project to use Junit 5 features to create interface based tests. Then a BlockingDeque implementation could easily pull in all the tests already written for BlockingDeque and its superinterfaces. Tests for interfaces would be found in a predictable location, e.g. test/j/u/c/BlockingDeque/. jtreg probably needs to have junit 5 support added. There should be testing folk excited about doing this! (The historic preference to have such tests in the JCK is an impediment ... )

On Wed, Oct 19, 2016 at 12:19 PM, Stuart Marks <stuart.marks at oracle.com> wrote:

On 10/18/16 11:00 AM, Martin Buchholz wrote: There's already a certain amount of mixing, e.g. stream tests sometimes test j.u.c. and Queue tests sometimes test all the Queue implementations. Unlike non-test code, some redundancy and divergence of testing frameworks and styles is fine. I still haven't found a way of writing shared tests for implementations of an interface that I really like.

It's probably the case that divergence of testing frameworks is unavoidable, or at least it's impractical. I doubt that it's worthwhile to rewrite all the straight jtreg tests into TestNG, or JUnit, or whatever. But I'd draw the line before saying this is "fine." [1] Maintaining the tests' organization is pretty important. Most of the collections tests are in jdk/test/java/util though they're spread around a bit uncomfortably even here. But now it's, oh, ArrayDeque and ArrayList.removeIf tests are over here instead. Having things spread around increases the likelihood of cases being missed or being tested redundantly. The test groups have to be maintained as well. I know I've been bitten by problems (not in collections) where I thought I had run the right set of tests, but it ended up that I hadn't, resulting in me breaking the build. As it turns out, jdkcollectionscore doesn't include any ArrayDeque tests. Hmmm. Well, maybe jdkcollectionscore isn't useful. It would have been nice to know this when I added it last year. :-/ [2] As things stand, I'm basically OK with this changeset going in. But it does seem to highlight some areas that need some future cleanup, particularly in the tests and the test group declarations. s'marks [1] http://knowyourmeme.com/memes/this-is-fine [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7a0c06013ae6

More information about the core-libs-dev mailing list