[issue39385] Add an assertNoLogs context manager to unittest TestCase
Kit Yan Choi added the comment: Thank you for looking into this. Yes, I agree it makes sense to have assertNoWarns for the same reason. -- ___ Python tracker <https://bugs.python.org/issue39385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39385] Add an assertNoLogs context manager to unittest TestCase
Change by Kit Yan Choi : -- keywords: +patch pull_requests: +17459 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18067 ___ Python tracker <https://bugs.python.org/issue39385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39385] Add an assertNoLogs context manager to unittest TestCase
New submission from Kit Yan Choi : assertLogs is really useful (issue18937). Unfortunately it does not cover the use cases where one wants to ensure no logs are emitted. Similar to assertLogs, we can have a context manager for asserting no logs, something like this?: with assertNoLogs(logger, level): ... If logs are unexpected found, the test would fail with the logs captured included in the error message. Happy to submit a PR if there is interest. -- components: Library (Lib) messages: 360250 nosy: Kit Yan Choi priority: normal severity: normal status: open title: Add an assertNoLogs context manager to unittest TestCase type: enhancement ___ Python tracker <https://bugs.python.org/issue39385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38296] unittest expectedFailure does not differentiate errors from failures
Kit Yan Choi added the comment: I think Python does differentiate "test error" and "test failure" such that a test outcome state can be one of these: success, failure, error, skipped. One could refine these to six: expected success, unexpected success, expected failure, unexpected failure, error, skipped. For example, in the documentation for failureException: * failureException: determines which exception will be raised when the instance's assertion methods fail; test methods raising this exception will be deemed to have 'failed' rather than 'errored'. Another evidence: unittest.runner.TextTestResult, there are methods called "addSuccess", "addError", "addFailure", "addSkip", "addExpectedFailure" and "addUnexpectedSuccess". For example, this test outcome is marked as "FAILED": def test(self): x = 1 y = 2 self.assertEqual(x + y, 4) == FAIL: test (test_main.T) -- Traceback (most recent call last): File "test_main.py", line 9, in test self.assertEqual(x + y, 4) AssertionError: 3 != 4 But the test outcome for this test is "ERROR": def test(self): x = 1 y = 2 + z # NameError self.assertEqual(x + y, 4) == ERROR: test (test_main.T) -- Traceback (most recent call last): File "test_main.py", line 8, in test y = 2 + z # NameError NameError: global name 'z' is not defined The issue here being "expectedFailure" converting "error" to "success", which is not expected, and is causing decorated tests to become unmaintained. While the rest of unittest differentiates "error" and "failure", expectedFailure does not. This is either a bug in the behaviour of expectedFailure, or a bug in the documentation for not being clear on the fact that unexpected error will be considered as expected failure (which I think is wrong). -- ___ Python tracker <https://bugs.python.org/issue38296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38296] unittest expectedFailure does not differentiate errors from failures
Kit Yan Choi added the comment: Pining Chris based on previous discussion in issue16997 ... Hope that's okay. I notice that the language in my initial message also conflates error and failure. My apologies on the carelessness. Just to clarify: @unittest.expectedFailure def test(self): THIS_VARIABLE_IS_UNDEFINED # ---> NameError should give: ERROR (errors=1) currently gives: OK (expected failures=1) By fixing this, we can help projects to maintain their tests decorated with expectedFailure so that the tests remaining to be meaningful. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue38296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38296] unittest expectedFailure does not differentiate errors from failures
Change by Kit Yan Choi : -- nosy: -Kit Choi ___ Python tracker <https://bugs.python.org/issue38296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38296] unittest expectedFailure does not differentiate errors from failures
Kit Yan Choi added the comment: For your test: class T(unittest.TestCase): def test_f(self): raise TypeError() If you run this test with unittest test runner, you should get this result: E == ERROR: test_f (test_main.T) -- Traceback (most recent call last): File "test_main.py", line 5, in test_f def test_f(self): raise TypeError() TypeError -- Ran 1 test in 0.000s FAILED (errors=1) I expect to get this behaviour even if the test is decorated with unittest.expectedFailure. However, currently we get a success. Scenario: You create a class named Duck with a method "quack". Then you added a test, and test needs to call Duck.quack. Later on for whatever reason, you need to decorate the test with expectedFailure. The test passes with the expected failure. Then you rename the "quack" method to "walk", but you forget to update the test. Now the test is actually failing with an AttributeError, but you won't notice it because expectedFailure silences it. In this scenario, it is important to differentiate a "test error" and a "test failure". A test has four status: success, failure, error, skipped. I expect unittest.expectedFailure to make "failure" a "success" and a "success" a "failure", and it should leave "error" and "skipped" unchanged. Please consider reopening this issue. -- nosy: +Kit Yan Choi ___ Python tracker <https://bugs.python.org/issue38296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30724] ZipFile.open treats directory path as empty file
New submission from Kit Yan Choi:
Given a zipfile with the following content:
subdir/
file1.txt
subdir/file2.txt
>>> archive = ZipFile(file_path, "r")
>>> f = archive.open("subdir/", "r")
>>>f.read()
b''
It is quite odd that the subdirectory can be opened as if it was an empty file.
One would expect it to raise.
One use case is that the archive is created using shutil.make_archive, which
includes the subdirectory paths in the namelist. Upon looping
ZipFile.namelist(), you end up opening a subdirectory and getting the empty
content, which should have led to error and prompted the developers to filter
the namelist first.
--
messages: 296564
nosy: Kit Yan Choi
priority: normal
severity: normal
status: open
title: ZipFile.open treats directory path as empty file
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue30724>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
