On Mon Jul 28 17:21:20 2025 +0000, Paul Gofman wrote:
I'd suggest to avoid such complicated and multivariant conditions in tests (there are also more like that), it is very hard to follow. E. g., maybe establish the condition whether the call is supposed to succeed or not and have separate ok's, and then maybe additionally split other cases, or, if the variance for how that fails depends on hardware configuration or Windows version maybe we don't care about detail of every failure status and can just limit those details to simplify the condition. Also, it seems like that this tests accepts just any result in the sense we care for: e. g., for hrs == S_OK it can be either S_OK or AUDCLNT_E_UNSUPPORTED_FORMAT. Is it really random in such cases across hardware whether it is OK or UNSUPPORTED_FORMAT? Or if it varies across different format and other cases, I think it would be valuable to distinguish in test when it is OK and when not, that seems to be directly related to the Wine implementation parts being touched. If that varies across Windows version I'd suggest to keep the latest as expected variant and keep the rest in broken().
E. g., a bit we want to know practically if specific channel configuration translation is supported between two given once, it would be great that the test would be showing that explicitly in some form, and not effectively accept any result from _Initialize.