| msg202887 - (view) |
Author: Zachary Ware (zach.ware) *  |
Date: 2013-11-14 21:00 |
| In test_winsound, PlaySoundTest.test_alias_fallback has been commented out for quite some time but has been reported as 'ok' ever since. Does anyone know what the current status of the test is? Should it still be skipped (explicitly)? Should it be marked as an expected failure? Would it be dangerous to enable? My own testing shows it to be harmless on my machine, but my range of test configurations is sorely limited at present. My own suggestion is to mark it as an expected failure (or just enable it wholesale, and mark it if it does prove flaky) and see what the buildbots make of it, but I don't want to do that if it could cause anything worse than an exception. Thoughts? |
|
|
| msg202897 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2013-11-14 21:44 |
| I believe that expected failure will give an error report if the test succeeds. |
|
|
| msg202904 - (view) |
Author: Zachary Ware (zach.ware) * |
Date: 2013-11-14 22:01 |
| It doesn't appear to; at least on 3.4 an unexpected success is silently ignored by regrtest in non-verbose mode and added to the report in verbose mode (e.g., "OK (skipped=1, unexpected successes=1)") or when run alone. |
|
|
| msg203088 - (view) |
Author: Ezio Melotti (ezio.melotti) * |
Date: 2013-11-16 21:40 |
| Maybe someone else can try it, or just enable it and see if the buildbots are happy (I think you can use custom builds as well for this kind of experiments). > at least on 3.4 an unexpected success is silently ignored by regrtest is this expected? |
|
|
| msg203405 - (view) |
Author: Zachary Ware (zach.ware) * |
Date: 2013-11-19 18:02 |
| I don't know that it's expected, but it doesn't appear to be unexpected. regrtest doesn't appear to know anything about expected failures or unexpected successes, mostly because both concepts appear at the individual test level while regrtest deals at the test module level. unittest docs don't actually say what happens when an expected failure fails to fail. As for this issue, it looks like the skipping of the test predates _have_soundcard and has_sound. If there are no objections, I'll try the attached patch on default; if it causes failures, I'll try a 'skipUnless(has_sound('SystemDefault')...', and if that work's I'll backport it to the other two branches. |
|
|
| msg204641 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2013-11-28 05:58 |
| New changeset 6f1c5d0b44ed by Zachary Ware in branch 'default': Issue #19595: Re-enable a long-disabled test in test_winsound http://hg.python.org/cpython/rev/6f1c5d0b44ed |
|
|
| msg204767 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2013-11-30 03:15 |
| New changeset 30b3798782f1 by Zachary Ware in branch '2.7': Issue #19595: Re-enable a long-disabled test in test_winsound http://hg.python.org/cpython/rev/30b3798782f1 New changeset 63f3e8670fa6 by Zachary Ware in branch '3.3': Issue #19595: Re-enable a long-disabled test in test_winsound http://hg.python.org/cpython/rev/63f3e8670fa6 |
|
|
| msg204768 - (view) |
Author: Zachary Ware (zach.ware) * |
Date: 2013-11-30 03:17 |
| As long as the buildbots stay happy, this test is back to actually testing. |
|
|