Updated: I misunderstand the SetErrorMode API, it's mode can be restored after the test. Now this PR is ready for review.

cc @serhiy-storchaka

import msvcrt
import unittest


class TestOther(unittest.TestCase):

   def test_SetErrorMode(self):
       origin = msvcrt.GetErrorMode()
       print(f"origin mode: {origin}")
       msvcrt.SetErrorMode(0)
       current_default = msvcrt.GetErrorMode()
       print(f"current default: {current_default}")
       for v in (msvcrt.SEM_FAILCRITICALERRORS, msvcrt.SEM_NOGPFAULTERRORBOX,
                 msvcrt.SEM_NOALIGNMENTFAULTEXCEPT, msvcrt.SEM_NOOPENFILEERRORBOX):
           if origin & v:
               print("set v:", v)
               msvcrt.SetErrorMode(v)
       self.assertEqual(origin, msvcrt.GetErrorMode())


if __name__ == "__main__":
   unittest.main()

python .\a.py
origin mode: 32771  (0x1 + 0x2 + 0x8000)
current default: 0
set v: 1 (0x1)
set v: 2 (0x2)
set v: 32768 (0x8000)
F
======================================================================
FAIL: test_SetErrorMode (__main__.TestOther)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\xxxxx\Source\cpython\a.py", line 18, in test_SetErrorMode
    self.assertEqual(origin, msvcrt.GetErrorMode())
AssertionError: 32771 != 32768

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)

These should pretty much all be used in every test run anyway, since we need them to avoid failed/error tests from hanging due to various popups that UCRT causes. I don't think we really gain anything by having additional tests.

I haven't reviewed the test implementations yet (might be a while before I can get to that), but make sure that there's 0% chance of ever failing and leaving the state corrupt here. That's the kind of thing that will make test runs hang instead of abort, which is far more of a problem than not having additional tests for these functions.

Hi @zooba, do you mean to put the test in a separate process to avoid making the process's state violated?

do you mean to put the test in a separate process to avoid making the process's state violated

We need to configure this state correctly for child processes as well, otherwise we risk the same hanging behaviour. So it doesn't make a huge difference.

What I really mean is we don't need to add these tests, because the functions are always used (when available), so if they're going to fail then the test run won't ever have started, and if they do fail, the entire test run is going to hang (because e.g. test_os will pop up assert dialogs that prevent progress). The situations where we would run these new tests and they provide any useful information are basically non-existent, as far as I can tell.

And if we run the new tests and anything at all goes wrong, then chances are we won't get a failed test, but a broken test run. So it makes it harder to diagnose the problem, because we won't see any info about it.

So I think we should close the PR without merging. But if someone else wants to make an argument for why we should include these tests despite the lack of usefulness and the risk of greater breakage, they should make those arguments and I might be convinced.

I think that it would be interesting to test these functions at least for out-of-range values. These calls should always fail and should not have side effect. I am not sure that all errors are correctly handled in the implementation, so we can get a successful call instead of exception.

Of course, we can test also successful calls if this is safe.

I think there are some read-only functions like GetErrorMode, which we can at least test.

Another thought is: can we add a special resource (for example, violate_process), so that we can test them in the local development environment? I'm not sure about this because maybe there are some build environments which enable the test with -uall?