René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Some xfail markings fail to validate their exception types","articleBody":"This bug was discovered by @Borda in #1888. Because that PR's central focus is tooling to catch typos, I'm creating this issue so that this bug in the test suite is clear, and so it will not be forgotten regardless of how development proceeds there. This affects three test cases in `test_index.py`.\r\n\r\nIn #1777, I introduced `test_run_commit_hook`. This is expected to fail in a couple of situations where it should nonetheless be feasible to run the test suite. One of these is when the tests are run on a (native) Windows system that has no `bash` that can be found in a path search, neither in `System32` or otherwise and neither WSL-related or otherwise. The test included an xfail marking to cover that case:\r\n\r\nhttps://github.com/gitpython-developers/GitPython/blob/53640535cf8314366a01da081947dd8504a299cd/test/test_index.py#L1018-L1022\r\n\r\nIn that PR I also added those xfail markings to other tests to which they applied, and I used copy and paste to reproduce the parts that should be exactly the same across them.\r\n\r\nBut that contains a typo, passing a `rasies` argument when constructing the mark, rather than the correct `raises` argument. The wrong argument is apparently ignored, so the marking is unconstrained, and even if those tests fail with a different exception -- one that is not covered by other xfail markings, and that is not intended to be covered by the ones with the misspelling, including `AssertionError` from an `assert` statement in the test -- the problem would not be caught.\r\n\r\nThis is distinct from the more common problem of misspelling a mark, which is also not an error, but which `pytest` does have the ability to warn about.\r\n\r\n**Fortunately, the way those tests fail is as the xfail markings attempt to describe and will actually describe once fixed.** I have retested the cases not covered on CI, and they work with the changes to `test_index.py` appearing in [a20d5db](https://github.com/gitpython-developers/GitPython/pull/1888/commits/a20d5db6dd2943057e8709769d131db9cf821611) (#1888). I only checked out the changes to `test_index.py` in testing this, not the other files. In a virtual machine running Windows Server 2022 (version 10.0.20348), I have just tested the cases where:\r\n\r\n- `bash.exe` exists, is the WSL-related command in `System32`, but there is no WSL system installed.\r\n- `bash.exe` exists, is not the WSL-related command in `System32` but is instead Git Bash, and is working.\r\n- `bash.exe` does not exist anywhere found in a `Popen` call, not even in `System32`.\r\n\r\nThe latter case I believe still occurs on some Windows systems that nothing unusual has been done to, but is rare because usually a WSL-related `bash.exe` appears in `System32` even if WSL is not installed, and (non-shell) path search on Windows generally includes `System32` automatically, and even places it before `PATH` directories even if it appears late or not at all in `PATH`.\r\n\r\n(I retested it the same way I had done originally: by saving a snapshot to restore, then using [NanaRun MinSudo](https://github.com/M2Team/NanaRun?tab=readme-ov-file#minsudo) to run a shell as the special TrustedInstaller user, which is permitted to delete even specially protected files in `System32`. I suggest against doing such a thing outside a virtual machine; I snapshotted the VM first and restored it after the test.)","author":{"url":"https://github.com/EliahKagan","@type":"Person","name":"EliahKagan"},"datePublished":"2024-04-01T02:15:08.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/1893/GitPython/issues/1893"}