[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Michael Foord added the comment: I like assertPermutation (with or without the Is, slight preference for without). -- ___ Python tracker <https://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38136] Remove AsyncMock.assert_awaited_*
Michael Foord added the comment: I'm particularly concerned that we have call_count "sane" for AsyncMock and avoid adding "await_count" if possible. I think we've decided on that. I'm more agnostic on the assert_await* methods. I agree they're a nice API. I don't mind those staying but I also don't mind them going. -- ___ Python tracker <https://bugs.python.org/issue38136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25597] unittest.mock does not wrap dunder methods (__getitem__ etc)
Michael Foord added the comment: The previous behaviour was unspecified and clearly due to missing functionality, so the advantages of fixing it outweigh any potential compatibility issues. But I'd see it as a feature enhancement for 3.9. -- ___ Python tracker <https://bugs.python.org/issue25597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25597] unittest.mock does not wrap dunder methods (__getitem__ etc)
Michael Foord added the comment: As discussed with Karthik, I think this is a nice feature enhancement for the wraps functionality and worth fixing. It has the great advantage that the fix is nice and isolated and simple. -- ___ Python tracker <https://bugs.python.org/issue25597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36871] Misleading error from unittest.mock's assert_has_calls
Michael Foord added the comment: (The code that generated functions was originally borrowed from the decorator module by Michele Simionato. When I first started in Python, around 2002, I was impressed by the Python community as it had two very prominent women amongst the part of the community I inhabited. Nicola Larosa and Michele Simionato. It turned out they were both Italian men.) -- ___ Python tracker <https://bugs.python.org/issue36871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36871] Misleading error from unittest.mock's assert_has_calls
Michael Foord added the comment: The code around whether or not to swallow self is hairy. Even if the original spec object is a class we may still be mocking an instance of the class (we don't want users to have to create an instance just to be able to use it as a spec). So we have to carry metadata about whether or not we're mocking an instance. But we also have to support the use case of when users are mocking an actual class object. This gets potentially recursive in the case of autospec and has to apply to the class object itself. If we're mocking an instance that is callable then the signature on the top level mock should be taken from __call__. If we're mocking the constructor the signature comes from __init__. So it's all complicated. And when I originally wrote the code it was worse as it predated inspect.Signature (and was one of the driving use cases for it) and created functions with the right signature by exec'ing code. So it's better code than it used to be, but I'm still scared of it and that particular bug came in the switch to use sig.bind which I didn't write. -- ___ Python tracker <https://bugs.python.org/issue36871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38122] AsyncMock force always creating an AsyncMock for child mocks
Michael Foord added the comment: That may change though, right? In general I dislike the proliferation of keyword arguments if it's at all possible to avoid. I added way too many of them originally and the mock API is really big. -- ___ Python tracker <https://bugs.python.org/issue38122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30587] Mock with spec object does not ensure method call signatures
Michael Foord added the comment: This will affect spec and spec_set. -- ___ Python tracker <https://bugs.python.org/issue30587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30587] Mock with spec object does not ensure method call signatures
Michael Foord added the comment: I'd like spec to have signature validation. I don't think the use case for "attribute validation only" (current spec behaviour) is very strong and I'd rather not add new keywords. The mock API is already too complex. I'll take the existing PR and modify it to use spec instead of adding the new autospec. -- ___ Python tracker <https://bugs.python.org/issue30587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34596] [unittest] raise error if @skip is used with an argument that looks like a test method
Change by Michael Foord : -- assignee: -> michael.foord components: +Extension Modules -Library (Lib), Tests resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34596] [unittest] raise error if @skip is used with an argument that looks like a test method
Michael Foord added the comment: I'm in favour of a default and "Unconditionally skipped" is fine with me. Although "Skipped" would also be fine. Making @skip work with no arguments is fine. Having to pass in arguments message arguments you don't want is a pain and there's no need to force the user. Let's add a default message and make the skipped tests report as skipped properly on 3.8 and close it. -- ___ Python tracker <https://bugs.python.org/issue34596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36674] "unittest.TestCase.debug" should honour "skip" (and other test controls)
Michael Foord added the comment: "I don't know why run() returns None for skipIf cases instead of returning a TestResult with non-empty skipped, as it does for skipTest, or if the None is a separate bug." That does sound like a bug. -- ___ Python tracker <https://bugs.python.org/issue36674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37668] Allow individual test to be specified by "#" or "."
Change by Michael Foord : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37668> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37669] Make mock_open return per-file content
Michael Foord added the comment: Can you suggest an API for doing this? -- ___ Python tracker <https://bugs.python.org/issue37669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Michael Foord added the comment: Or even making the assert methods into custom descriptors. -- ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Michael Foord added the comment: Hmm, it could be done by __init_subclass__ potentially. -- ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Michael Foord added the comment: Suppose failureException is set to TypeError on that TestCase class, how would your assertEquals signal failure to the test runner? -- ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Michael Foord added the comment: Has anyone seen any real world use cases for failureException? It's a real hindrance to a whole bunch of changes sounds decoupling. On the other hand something like assertThat could catch a custom exception from the matchers (subclass of AssertionError) and raise failureException -- ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30587] Mock with spec object does not ensure method call signatures
Michael Foord added the comment:
Spec objects are currently dumb. It would be a new feature to add signature
validation to them.
I think it would be a useful feature though as currently autospec sort of
obsoletes spec objects whilst being more heavyweight and harder to use.
I think it would appropriate to add to 3.8 but not to 3.7.
Compatibility with existing tests is the issue. The obvious answer is a flag to
turn it on/off but that adds complexity to the API.
My gut feeling is that spec objects are far more commonly used in situations
where validation would be useful than a detriment.
> On 31 Mar 2019, at 18:07, Karthikeyan Singaravelan
> wrote:
>
>
> Karthikeyan Singaravelan added the comment:
>
> I am slightly concerned if spec should gain more responsibility than just
> validating attribute access which is mentioned in the docs. With the linked
> PR spec below would also validate the signature which is not done in Python
> 3.7 so this might break code for someone who only wants to validate access
> attribute access and not signature of the methods. It seems the PR also adds
> autospec argument to Mock that is currently not supported though spec and
> spec_set are supported.
>
> from unittest import mock
>
> def foo(lish):
>pass
>
> mock_foo = mock.Mock(spec=foo)
> mock_foo(1, 2)
>
> try:
>mock_foo.non_existent
> except AttributeError:
>print("raises AttributeError for non-existent attribute")
>
> # 3.7
>
> ➜ cpython git:(pr_1982) python3.7 /tmp/foo.py
> raises AttributeError for non-existent attribute
>
> # With PR
>
> ➜ cpython git:(pr_1982) ./python.exe /tmp/foo.py
> Traceback (most recent call last):
> File "/tmp/foo.py", line 7, in
>mock_foo(1, 2)
> File
> "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py",
> line 1009, in __call__
>_mock_self._mock_check_sig(*args, **kwargs)
> File
> "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py",
> line 103, in checksig
>sig.bind(*args, **kwargs)
> File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/inspect.py",
> line 3016, in bind
>return args[0]._bind(args[1:], kwargs)
> File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/inspect.py",
> line 2937, in _bind
>raise TypeError('too many positional arguments') from None
> TypeError: too many positional arguments
>
> --
>
> ___
> Python tracker
> <https://bugs.python.org/issue30587>
> ___
--
___
Python tracker
<https://bugs.python.org/issue30587>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36485] Add a way to clear all caches
Michael Foord added the comment: Tests codify knowledge about the system under test, so it doesn't matter that the test suite has to know how to clear caches. It's specifically a good thing that the test writer knows which caches exist and need clearing, and how to do it. The harder thing mighty be determining what scope to do the clearing (per test, class or module) bit unittest exposes hooks for fixtures at those points for anything that needs doing automatically. -- ___ Python tracker <https://bugs.python.org/issue36485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36485] Add a way to clear all caches
Michael Foord added the comment: > On 30 Mar 2019, at 23:48, Michael Foord wrote: > > > Michael Foord added the comment: > > An auto-magic cache clearing mechanism is really tempting. I tend to agree > with Raymond though, if code needs and progress a cache clearing mechanism it > should be treated and accessible. * exposes (not progress) * tested (not treated) Sorry. > > They're are probably some problematic caches still within unittest however. > Do test results still keep alive all tracebacks until test reporting? > > -- > > ___ > Python tracker > <https://bugs.python.org/issue36485> > ___ -- ___ Python tracker <https://bugs.python.org/issue36485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36485] Add a way to clear all caches
Michael Foord added the comment: An auto-magic cache clearing mechanism is really tempting. I tend to agree with Raymond though, if code needs and progress a cache clearing mechanism it should be treated and accessible. They're are probably some problematic caches still within unittest however. Do test results still keep alive all tracebacks until test reporting? -- ___ Python tracker <https://bugs.python.org/issue36485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36366] Patcher stop method should be idempotent
Michael Foord added the comment: It's almost certainly an oversight rather than a design decision. I'd be happy with the change you suggest Karthikeyan. -- ___ Python tracker <https://bugs.python.org/issue36366> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35226] mock.call equality surprisingly broken
Michael Foord added the comment: Parents comparing upwards sounds like the right (and simple) fix. Not breaking the tuple tests would be good. I'm happy for Chris to produce the patch. -- ___ Python tracker <https://bugs.python.org/issue35226> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33236] MagicMock().__iter__.return_value is different from MagicMock().__iter__()
Michael Foord added the comment: This isn't a bug. This is the intended behaviour, otherwise MagicMock objects would error out on iteration. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14266] pyunit script as shorthand for python -m unittest
Change by Michael Foord : -- resolution: -> rejected ___ Python tracker <https://bugs.python.org/issue14266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32299] unittest.mock.patch.dict.__enter__ should return the dict
Michael Foord <mich...@voidspace.org.uk> added the comment: This seems like a reasonable feature request. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32299> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32632] Mock does not create deepcopy of mutable args
Michael Foord <mich...@voidspace.org.uk> added the comment: There are several disadvantages to doing deepcopy: * identity checks now fail * deep copying is slow * deep copying doesn't work on arbitrary objects So deep copying by default isn't a good idea. This particular case is mentioned in the docs, with an example of a deep-copying mock if you need one. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30821] unittest.mock.Mocks with specs aren't aware of default arguments
Michael Foord added the comment: Generally the called with asserts can only be used to match the *actual call*, and they don't determine "equivalence". To do it cleanly would be tricky, and adding complex code is a maintenance burden. I'm not convinced there's a massive use case - generally you want to make asserts about what your code actually does - not just check if it does something equivalent to your assert. So I'm not enthusiastic about this. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30821> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30541] Add restricted mocks to the python unittest mocking framework
Michael Foord added the comment: Note that you can use an object as the parameter to the spec argument rather than just a list of attributes. Hmmm... I'm not totally opposed to the addition of a "seal_mock" method (optionally with a recurse boolean for child mocks) being added to the Mock/MagicMock classes. It's quite a nice API. I don't like the idea of an additional Mock class for this. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30541] Add restricted mocks to the python unittest mocking framework
Michael Foord added the comment: I don't see what this buys over spec and autospec. I'd be inclined to close it without a compelling use case beyond what is already supported. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30221] Deprecate assertNotAlmostEqual
Michael Foord added the comment: I agree it's not *very* useful, but I don't see any benefit in getting rid of it either. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28911] Clarify the behaviour of assert_called_once_with
Michael Foord added the comment: I like the documentation improvement, thank you. (The purpose of the method is to combine an assert about the arguments the method was called with and an assertion that it was only called once. To change the semantics would be both undesirable and backwards incompatible.) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29274] Change “tests cases” → “test cases”
Michael Foord added the comment: Yep, looks like an improvement to me! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20804] Sentinels identity lost when pickled (unittest.mock)
Michael Foord added the comment: LGTM Serhiy - thank you for your work. Appreciated. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20804] Sentinels identity lost when pickled (unittest.mock)
Michael Foord added the comment: It's a new feature. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20804] Sentinels identity lost when pickled (unittest.mock)
Michael Foord added the comment: I think option 3 is the correct semantic behaviour for sentinels, and if there are already examples of this in the standard library then it *doesn't* violate expected behaviour of pickling and copying (sentinel and singleton objects can be permitted to retain this property through copying and pickling if it is a document facet of their behaviour and a natural result of their use cases). Sentinels exist *purely* to have unique, *identifiable* objects. So retaining identity is their "expected behaviour" as identity is their defining feature. So Serhiy, if you're happy that you've implemented this correctly - with tests and documentation updates (I see a separate doc patch) - go ahead and commit. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20804] Sentinels identity lost when pickled (unittest.mock)
Michael Foord added the comment: So my thinking has evolved slightly on it. If it's *possible* for sentinels to be copied and pickled and preserve identity then I'm happy for it. I think the right semantics for copying a sentinel is that you get the original object back. If you pickle a sentinel and then unpickle back *into the same process* you should get the same object back. David worried that this confuses the semantics of pickling/copying because it isn't generally the case - so I'm open to further discussion on it, but if Serhiy has fixed the "problem" here I'm happy for it to go in. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28961] unittest.mock._Call ignores `name` parameter
Michael Foord added the comment: Yep, LGTM as well. Nicely spotted! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28919] Simplify `_copy_func_details` in unittest.mock
Michael Foord added the comment: Yep, looks good to me to. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28733] Show how to use mock_open in modules other that __main__
Michael Foord added the comment: open shouldn't always be patched in builtins, it's much better to patch it in the specific namespace it's being called from. So the doc patch here shouldn't be applied as is. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28569] mock.attach_mock should work with any return value of patch()
Michael Foord added the comment: Oh, I see what you mean - an attribute that doesn't exist on the original. With autospec that should throw an exception (AttributeError) I think, yes. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28569] mock.attach_mock should work with any return value of patch()
Michael Foord added the comment: It should be perfectly valid to use attach_mock with an attribute that doesn't already exist. Part of it's purpose is to create new attributes. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28569] mock.attach_mock should work with any return value of patch()
Michael Foord added the comment: Sure, go ahead Syed. Feel free to ask any questions you may have. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28569] mock.attach_mock should work with any return value of patch()
Michael Foord added the comment: attach_mock should use function.mock when it is passed a function created by autospec. It should also *probably* fail if given a non-mock object (although that would prevent people duck-typing and attaching a mock-like object so I'm open to discussion on that). -- stage: -> needs patch versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28054] Diff for visually comparing actual with expected in mock.assert_called_with.
Michael Foord added the comment: I like the idea and would be happy for it to be added to mock. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28318] Python unittest.mock.mock_calls stores references to arguments instead of their values
Michael Foord added the comment: This is a deliberate design decision of mock. Storing references works better for the more general case, with the trade-off being that it doesn't work so well for mutable arguments. See the note in the docs with a workaround: https://docs.python.org/3/library/unittest.mock-examples.html#coping-with-mutable-arguments -- resolution: -> not a bug status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28318> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27376] Add mock_import method to mock module
Michael Foord added the comment: Before you spend any more time on this, my current thinking is that this is a bit too specialised to belong in the standard library. I'll wait and see if a preponderance of core devs and other users disagree with me before I close this though. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27376] Add mock_import method to mock module
Michael Foord added the comment: It's not a use case I've specifically had but I can see its use. I'm uncertain of whether that means it belongs in the module or not. Let me see if I can get some more eyes on this bug. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27376] Add mock_import method to mock module
Michael Foord added the comment: Is this for mocking out runtime dependencies that aren't available at test time? It seems like a good way of masking bugs! I'd be happier with a (or at least an option) to specify the imports that should be mocked. The use case should be mentioned in the docs. I think the name is slightly confusing. I originally thought this was a function to mock specific imports - not to catch failed imports. mock_missing_import (or similar) would be a better name. It's common with the mock functions to be able to provide a class to use as the mock function, and to take arbitrary keyword arguments to pass to the mock constructor. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27376] Add mock_import method to mock module
Changes by Michael Foord <mich...@voidspace.org.uk>: -- assignee: -> michael.foord ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Michael Foord added the comment: I agree with David, I don't like the name but it is at least accurate (if you already understand what it does). assertItemsEqual was better but misleading. In the absence of a *dramatically* better name leave it alone. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26323] Add assert_called() and assert_called_once() methods for mock objects
Michael Foord added the comment: Yes, this can go in. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26323] Add assert_called() and assert_called_once() methods for mock objects
Michael Foord added the comment: There have been persistent calls for an "assert_called" method over the lifetime of mock. In the past I've rejected them because you can easily get it by asserting the call count is non-zero and I want to avoid the proliferation of a thousand assert methods. The demand is certainly consistent, so it would seem that people feel there is a use case. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20109] TestProgram is mentioned in the unittest docs but is not documented
Michael Foord added the comment: TestProgram is an abomination, but it has been publicly exposed in unittest since forever. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26232] Mock(spec=spec) has no effect
Michael Foord added the comment: create_autospec and Mock(spec=spec) are very different. Mock(spec=spec) creates a mock object with the same *attributes* as the original. It does not create functions like create_autospec can. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26140] inspect.iscoroutinefunction raises TypeError when checks Mock of function or coroutinefunction
Changes by Michael Foord <mich...@voidspace.org.uk>: -- nosy: -gvanrossum ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25520] unittest load_tests protocol not working as documented
Michael Foord added the comment: To find and run tests recursively from a test package you want test discovery rather than (necessarily) load_tests. For a bug report, please describe the behaviour you expect and the behaviour you're seeing instead. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26140] inspect.iscoroutinefunction raises TypeError when checks Mock of function or coroutinefunction
Michael Foord added the comment: In inspect checking that __code__ is a code object, or that co_flags is an int, would be better than special casing mock. However, the patch to mock looks reasonable to me. It copies the whole code object from the original function to the mock object. The patch needs a test (I'd like to see a test for the Mock(func) case and the create_autospec(func) case.) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25900] unittest ignores the first ctrl-c when it shouldn't
Michael Foord added the comment: Suggested behaviour sounds good, patch looks sensible. Is it possible to add a test too? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22138] patch.object doesn't restore function defaults
Michael Foord added the comment: Sean's patch looks good to me. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22138> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25669] unittest.assertEqual() on un-equal types inheriting from collections.Mapping
Michael Foord added the comment: assertEqual *does* do type checking and it's strict that it will only resort to the "type specific" assert checks if both types are of the same type. In the general case it's impossible to know whether comparing a subclass with the type specific check is the right thing to do - so unittest doesn't guess. As you have a simple workaround ( dict(foo) ) I'm closing this. -- resolution: -> rejected status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call
Michael Foord added the comment: I'm happy to blacklist __wrapped__ in call. I don't see how call can detect that kind of introspection in the general case though. Limiting call depth would be one option, but any limit is going to be arbitrary and I don't "like" that as a solution. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24928] mock.patch.dict spoils order of items in collections.OrderedDict
Michael Foord added the comment: Patch looks good to me. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call
Michael Foord added the comment:
Have you read the docs for call? :-)
call.foo("foo") generates a call object representing a method call to the
method foo. So you can do.
m = Mock()
m.foo("foo")
self.assertEqual(m.mock_calls, call.foo("foo"))
(etc)
See also the call.call_list (I believe) method for assertions on chained calls.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25532>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call
Michael Foord added the comment: Preventing the use of "__" attributes would limit the usefulness of call with MagicMock and the use of magic methods. That might be an acceptable trade-off, but would break existing tests for people. (i.e. it's a backwards incompatible change.) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call
Michael Foord added the comment: For mock I think your proposed fix is fine. call is particularly magic as merely importing it into modules can cause introspection problems like this (venusian is a third party library that has a similar issue), so working around these problems as they arise is worthwhile. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25000] _mock_call does not properly grab args and kwargs
Michael Foord added the comment: This is actually the specified and documented behaviour of mock when it is passed mutable arguments. Deep copying arguments on calls is rife with potential problems (not everything can be copied and it breaks comparison by identity). The documentation suggests ways around this: https://docs.python.org/3/library/unittest.mock-examples.html#coping-with-mutable-arguments -- resolution: -> not a bug status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25000> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22197] Allow better verbosity / output control in test cases
Michael Foord added the comment: Using the runner as a "context" passed to test cases (and accessible from tests) for this kind of configuration seems like a good approach to me. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7175] Define a standard location and API for configuration files
Changes by Michael Foord <mich...@voidspace.org.uk>: -- nosy: -michael.foord ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24193] Make LOGGING_FORMAT of assertLogs configurable
Michael Foord added the comment: assertLogs is on a Python test suite helper, not TestCase itself. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24193 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24857] Crash on comparing call_args with long strings
Michael Foord added the comment: call_args is not user settable! It is set for you by the mock when it is called. Arguably it could be a property instead. -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24857 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24857] Crash on comparing call_args with long strings
Michael Foord added the comment: Oops, I misunderstood the bug report - however, call_args is a tuple, so you can't compare it directly to a string like that. Please refer to the docs on using call_args. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24857 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24857] mock: Crash on comparing call_args with long strings
Michael Foord added the comment: Ok, fair enough. -- resolution: not a bug - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24857 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24651] Mock.assert* API is in user namespace
Michael Foord added the comment: I had a chance to talk to Guido about this at EuroPython. His feeling was that a separate set of functions *is* a better API - or at least would have been if mock had been designed this way from the start. However, the most serious problem with the current API is solved (as assert* attributes that don't exist now raise an AttributeError) and it isn't worth breaking people's code by deprecating then removing the assert methods just for a slightly cleaner API. As I agree about breaking code I'm inclined to close this with WontFix unless someone has strong feelings that it should be left open. (Thanks Robert for the proposal - it's hard for me not to feel emotionally attached to the current API, which makes it correspondingly hard to be objective about it, but I appreciate people's desires to improve mock.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24651 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21750] mock_open data is visible only once for the life of the class
Michael Foord added the comment: So the problem with the testing-cabal issue 280 is *really* a problem with decorators - the decorator is applied at method creation time and mock_open is only called once rather than once *per call*. Better would be to use mock.patch as a context manager inside the test, so that mock_open is (correctly) called each time. From a purist point of view I think that the Python 3.5==mock 1.1.4 behaviour is *better*. Whether that's enough justification to break existing code is a difficult question. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21750 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24651] Mock.assert* API is in user namespace
Michael Foord added the comment: I'm not wild about this idea. The problem with the assert methods has *essentially* been solved now, so I'm not convinced of the need for this change (unless users really *need* to have their own mocked attributes like assert_called_with which I think is highly unlikely). Part of the genius of mock was providing a flexible mock object that also encapsulated simple methods for introspecting/asserting how it has been used. Changing to require users to import/know about a whole host of separate functions doesn't feel like an improvement to me. That's aside from the whole breaking people's code for no tangible benefit issue. I acknowledge that other people, Carl for example, have different opinions - but from talking to many, many mock users over the years I think that those with the philosophically purist approach are in a minority to those who appreciate the more practical approach that mock takes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24651 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24656] remove assret from mock error checking
Michael Foord added the comment: -1 The whole thread is absurd. I'm travelling for europython and only have internet access on my phone until tomorrow at the earliest. On Saturday, 18 July 2015, Berker Peksag rep...@bugs.python.org wrote: Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +kushal.das, ncoghlan, rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24656 ___ -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15836] unittest assertRaises should verify excClass is actually a BaseException class
Michael Foord added the comment: The change to unittest is fine. I'd prefer the tests tweaking as Ezio suggested. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15836 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15836] unittest assertRaises should verify excClass is actually a BaseException class
Michael Foord added the comment: I like the first variant suggested by Ezio as more concise. I'll try and look at the substance of the patch today. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15836 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23469] Delete Misc/*.wpr files
Michael Foord added the comment: What is the advantage to deleting the Wing IDE project files, other than making it harder to use Wing to work on Python? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23469 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20487] Odd words in unittest.mock document.
Michael Foord added the comment: Patch looks good, thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20487 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21600] mock.patch.stopall doesn't work with patch.dict to sys.modules
Michael Foord added the comment: Using patch.dict manipulates the contents of sys.modules, it doesn't replace sys.modules. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21600 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21600] mock.patch.stopall doesn't work with patch.dict to sys.modules
Michael Foord added the comment: why not? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21600 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22823] Use set literals instead of creating a set from a list
Michael Foord added the comment: Patch looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22823 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22894] unittest.TestCase.subTest causes all subsequent tests to be skipped in failfast mode
Michael Foord added the comment: Looks good, thanks for the quick response. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22894 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22894] unittest.TestCase.subTest causes all subsequent tests to be skipped in failfast mode
Changes by Michael Foord mich...@voidspace.org.uk: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22894 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22827] Backport ensurepip to 2.7 (PEP 477)
Changes by Michael Foord mich...@voidspace.org.uk: -- nosy: -michael.foord ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22827 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22858] unittest.__init__:main shadows unittest.main
Michael Foord added the comment: One way would be to have an _main.py and have main.py import * (or equivalent) from it. We can't get rid of unittest.main being an alias for TestProgram - that's been around forever. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22858 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22860] unittest TestProgram hard to extend
Michael Foord added the comment: TestProgram is an abomination. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22860 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22813] No facility for test randomisation
Michael Foord added the comment: The point is that it is easy to have unintentional dependencies between tests. Test a sets up some state that test b relies on. This means that test b passes, so long as test a has already run. This is bad, tests should be isolated - it also means you can break test b when you change test a. Randomising test run order means you discover these unintentional dependencies earlier. With test randomisation you ideally need the seed to be displayed as part of the test run, and you need to be able to run with a particular seed. This enables you to reproduce failures, or odd results, from any particular test run. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22813 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22827] Backport ensurepip to 2.7 (PEP 477)
Michael Foord added the comment: mock in the Python standard library is licensed under the PSF license. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22827 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22431] Change format of test runner output
Michael Foord added the comment: I agree with Robert that the text output of the default runner should not be considered a part of the api that we make backwards compatible guarantees about. People who want to customise that should be customising the text runner/result. (Unfortunately it requires tinkering with both at the moment.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22431 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10611] sys.exit() in a test causes a test run to die
Michael Foord added the comment: Allowing sys.exit() to end the test run was particularly a problem for testing command line tools, where improper patching / unexpected code paths would trigger a sys.exit. If a test framework author wants a way to end the test run I'm happy to provide that (a custom exception to raise or a flag to turn off sys.exit handling), but I don't think having sys.exit kill test runs is best for test authors. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10611 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22680] Blacklist FunctionTestCase from test discovery
Michael Foord added the comment: I agree. -- title: unittest discovery is fragile - Blacklist FunctionTestCase from test discovery ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22680 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22457] load_tests not invoked in root __init__.py when start=package root
Michael Foord added the comment: With one minor doc change (break up the really long sentence), this looks good to go to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22680] unittest discovery is fragile
Michael Foord added the comment: Ah. Test discovery is discovering FunctionTestCase and attempting to instantiate it as a test. And failing. Maybe discovery should special case that class and not treat it as a normal TestCase. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22680 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
Michael Foord added the comment: Assertions are not uncommon in setUp. setUp is for setting up common state shared between tests and I regularly want to assert that state creation / preconditions are correct. I've never been bitten by this issue (I rarely use expectedFailure), but it's worth noting the use case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
Michael Foord added the comment: Maybe if the expectedFailure is applied to the whole class and it's the setUp that is unable to work. I've never seen it used that way of course (mostly because it doesn't work that way) - but I *can* imagine it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22680] unittest discovery is fragile
Michael Foord added the comment: I assume you mean you get the error *with* 3.5 (not without). Does this happen *every time* (i.e. is it trivially reproducible) - or can you provide a repro? This is regression that I would *assume* (a totally lazy assumption) introduced by the new error handling code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22680 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
