RFR: 8275170: Some jtreg sound tests should be marked with sound keyword [v3]
Phil Race
prr at openjdk.java.net
Fri May 20 22:31:38 UTC 2022
> This fix adds "headful sound" keywords to a number of javax/sound jtreg tests
>
> The jtreg javax.sound tests are written in such a way that if a needed audio device
> or other platform resource is not available, they just exit with a "pass" for the test.
> It is as if headful tests just swallowed HeadlessException and issued a pass.
> If we allowed that we'd be effectively testing almost nothing of real importance.
>
> Currently almost all sound tests have no keyword like "headful" to indicate they
> may need access to a hardware resource to do anything useful so a similar
> situation arises there except when someone runs those tests manually on
> a local system which has audio devices.
>
> Of course "headful" and "audio device" aren't exactly interchangeable terms
> but if tests are allowed to be run - or worse usually or always run - in a situation
> where they potentially are on a system without an audio device (a headless VM) or are running in
> a session which doesn't have full desktop access - which may in some
> cases be how audio device access is granted, then they are more likely
> to be running in this scenario where the testing isn't valid.
>
> Another point is that headful tests must be run one at a time - no concurrency because
> you can't have multiple tests moving the mouse at the same time
> Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM
> When tests that really need access to an audio device are run it is probably safer to consider
> the headful attribute as implying one test at a time is best .. granted on a desktop it isn't
> usual for a single app to be able to monopolize access to a speaker, but for input devices
> that is what you'd generally expect.
>
> By no means am I sure that the tests being updated here are the full set that need tagging.
> There are a lot of tests and they are all known to pass on systems with NO audio
> devices, so the search has been for tests which call APIs which will definitely
> need access to some device in order to do anything useful.
> So likely there are more to be added - either by a reviewer pointing them out or by later discovery.
> Alternatively we could mark ALL sound tests headful .. but given where we are starting from
> that might be erring unnecessarily far in the opposite direction.
>
> By adding both headful and sound keywords it gives options to someone who
> wants to identify the tests and perhaps run just tests which need "sound" on some
> config they know supports audio but isn't headful.
Phil Race has updated the pull request incrementally with one additional commit since the last revision:
8275170
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6086/files
- new: https://git.openjdk.java.net/jdk/pull/6086/files/98d02ae2..b7e0443e
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6086&range=02
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6086&range=01-02
Stats: 57 lines in 57 files changed: 0 ins; 0 del; 57 mod
Patch: https://git.openjdk.java.net/jdk/pull/6086.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6086/head:pull/6086
PR: https://git.openjdk.java.net/jdk/pull/6086
More information about the client-libs-dev
mailing list