On Fri, 6 Jan 2023 23:18:00 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>> Andy Goryachev has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 101 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8293119.constrained >> - 8293119: removed debug printouts >> - Merge remote-tracking branch 'origin/master' into 8293119.constrained >> - width indicator in tester >> - 2023 >> - 2023 >> - small delta >> - whitespace >> - whitespace >> - Merge remote-tracking branch 'origin/master' into 8293119.constrained >> - ... and 91 more: https://git.openjdk.org/jfx/compare/ca29cc61...795d196e > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ResizeHelperTest.java > line 214: > >> 212: */ >> 213: //@Test // this test takes too much time! >> 214: public void testWidthChange() { > > Do you think testing a pseudo-random subset of the combinations would be > interesting? > > Loosely related to this, it might be useful follow-up test enhancement to add > a generic `long.running.test` system property (or similar) that could be set > when a `LONG_RUNNING_TEST` gradle property is set (similar to what we do for > `unstable.test`). That way this, and other similarly exhaustive tests, could > be run explicitly when desired. Perhaps a combination of a number of typical tree/table configurations and a pseudo-random set could be added. I would rather add it as a part of [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), since the new algorithm (simulated annealing) would have the constraint checks embedded in it on one hand, and on the other it would need a different set of tests, for example to verify that it converges. A LONG_RUNNING_TEST is a good idea in general, I agree. The problem with this particular test, and the reason why i did not pursue it, is that it does not finish in 40 minutes, which is way too long for a test. I would like to think about it a bit longer, if I may. ------------- PR: https://git.openjdk.org/jfx/pull/897
