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.ma...@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, jdk_collections_core doesn't include any ArrayDeque tests. > Hmmm. Well, maybe jdk_collections_core 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 > >
