On Thu, 19 Aug 2021 06:49:14 GMT, Prasanta Sadhukhan <psadhuk...@openjdk.org> wrote:
> > > Since FIRST failure is > > > java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java > > > I tried to find tests that uses VK_SHIFT key which are … > > > > > > Can you reproduce the failure locally if the tests are run in the same > > order? > > Yes and no. These tests fail in my local system but not with same error > message. > It is known that some CI test failures is difficult to reproduce locally due > to system configuration and environment configuration(via KVM) in CI is quite > different from local personal laptop so timing matters. Yeah, I know. Local environment is usually faster and more responsive. > Also, it seems that these failures are intermittent. I waited for few days > but it has not happened since, so it 's difficult to pinpoint what test > timing issue is causing that. Do you mean that none of these tests has failed recently? Could it be that another test stopped failing and, as a consequence, this test doesn't fail either? > Also, I admit that the test changes are masking this timing issues, but the > changes are not wrong. If the original test author had used toLowerCase() > initially, I don't think anyone would have objected as the test just checks > for new characters without any distinction between lowercase/uppercase and > this change would prevent this swing tests from failing. I don't see why the original author would've bothered with `toLowerCase` when Shift or Caps Lock is never pressed in the test. The test doesn't fail if it's run outside the long running test suite, does it? This means the test is correct as it is written now, its failure is caused by another misbehaving test which most likely has left Shift key pressed. As an experiment, is it possible to log the current state of modifier keys, i.e. Shift, Control, Alt, before the key events are sent to edited table cell? This would confirm our guess whether Shift key is left pressed by a test which ran before. To be clear, I'm not objecting this change, however, it doesn't feel right to me. At the same time, it's the quickest way to make the test pass. I'm pretty sure most of the tests dealing with text input don't use `toLowerCase` when the actual and expected values are compared. ------------- PR: https://git.openjdk.java.net/jdk/pull/5079
