The thing to understand is that any failure of "make test" due to either default configuration or a bug in anything other than wine is a failure of the test system. If "make test" passed, and Alexandre committed a patch, then this patch MUST pass on all machines. If that's not the case, then people will (and do) not use the test infrastructure, and more tests fail. That's not good!
As such, I think you should fix your test to not fail (or mark it as a test wine does not pass). If you have different behaviors whether the driver bug exists or not on my system, split the test into two parts. This way, you can have one test that passes on wine whether or not the driver is broken (i.e. - if the bug in wine comes up, ignore it). The second test is one that fails if the bug in the driver doesn't come up, and if the bug in the driver does come up, fails if wine handles it differently from Windows. Mark this test as "fails on wine" until you fix it.
This way, the tests won't fail on my machine, regardless of how it is set up. Like I said, getting the tests to pass on all wine hackers machines is crucial to build confidence with the tests, thus allowing people to run the tests prior to sending patches.
If you are in Stuttgart, feel free to grab me and talk about it.
Shachar
Robert Reif wrote:
Shachar Shemesh wrote:
The problem is that I'm not interested in this test. I just think that, off the shelf, tests should not fail. My opinion is that if this is not a problem with Wine, it shouldn't fail the test.
The issue from a test perspective is that wine fails differently than windows under this situation. Wine really does initialization at CoCreateInstance and our Initialize really does nothing. Wine should fail at Initialize, not CoCreateInstance. Moving initialization to Initialize will require some restructuring of the code in dsound.dll. I'll look into it but won't promis any fixes real soon.