On Fri, 22 Oct 2021 19:01:27 GMT, Phil Race <p...@openjdk.org> wrote:
> 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. This makes the tests eligible to be run on headful systems. In practice it seems like ONLY headful systems actually have the sound devices. The sound keyword isn't understood by anything yet, so adding headful is the only way we have right now of ensuring these tests are eligible to be run on systems that have the necessary support. As I explained in the initial PR description headful is also useful for implying exclusive access. And without this keyword it means that these tests are ALWAYS run on systems without sound device support. So for years we've effectively problem listed these tests due to the tests not having headful and silently passing when there's no sound. Without headful no one runs these on systems that have the needed device. So this solves a big hole that we aren't testing this case. The 2 keywords give flexibility - anyone who wants to filter when its marked headful and needing sound can do this, but just adding sound right now will solve nothing. And there are a couple of tests NOT in OpenJDK that already do this so we have precedent - and in a previous life one was added by you and the other approved by you .. ------------- PR: https://git.openjdk.java.net/jdk/pull/6086
