[issue14408] Support ./python -m unittest in the stdlib tests

Zachary Ware added the comment: The test_socket patch is incomplete with the way I've been converting test modules, but it is a good starting point. Should this issue be renamed to be specifically for test_socket? The necessity of reaping threads at the end of the test poses a bit of an issue

[issue14408] Support ./python -m unittest in the stdlib tests

R. David Murray added the comment: Zach, what about the test_socket patch? -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue14408] Support ./python -m unittest in the stdlib tests

Zachary Ware added the comment: I just happened across this issue, which I think has been superseded by issues #16748 and #16968. -- nosy: +zach.ware ___ Python tracker ___

[issue14408] Support ./python -m unittest in the stdlib tests

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue14408] Support ./python -m unittest in the stdlib tests

Matt Joiner added the comment: Attached is a patch for test_concurrent_futures, similar to the patch for test_socket. -- Added file: http://bugs.python.org/file25088/test_concurrent_futures-unittest-discoverability.patch ___ Python tracker

[issue14408] Support ./python -m unittest in the stdlib tests

Matt Joiner added the comment: The patch attached, rejigs the TestCase inheritance in test.test_socket so that tests run correctly using unittest discovery. Recent changes have made test_queue, and test_threading run without similar fixes, so I don't think fixes for those are necessary anymor

[issue14408] Support ./python -m unittest in the stdlib tests

Matt Joiner added the comment: It could in fact be necessary, if the inheritance cannot be juggled to give the right MRO. Fortunately this is not the case, I should have a patch using TestCase inheritance for discovery tomorrow. -- ___ Python trac

[issue14408] Support ./python -m unittest in the stdlib tests

R. David Murray added the comment: The convention in the stdlib is to name the mixin classes TestXXXBase. Granted, a lot of those inherit from TestCase. I have no objection to calling them Mixin instead, I'm just pointing out that there is an existing convention. (As an aside, when I first

[issue14408] Support ./python -m unittest in the stdlib tests

Michael Foord added the comment: Besides which, the mixin pattern won't *stop* working if we provide this extra functionality - it would just be an alternative for those (like myself) who think it impedes code readability. :-) At this point we're off topic for the *specific issue*, and I'm fi

[issue14408] Support ./python -m unittest in the stdlib tests

Michael Foord added the comment: It still looks weird to see code calling methods that obviously don't exist, and with no indication *at the call site* where they come from. Making it clearer with naming would help: "TestThingMixin" or similar. There are classes like this in the unittest test

[issue14408] Support ./python -m unittest in the stdlib tests

R. David Murray added the comment: I guess I'm not really done talking about this, though my bow to you as maintainer still stands. The mixin tests *can't* be run in isolation, that's the whole point. Otherwise you could just let unittest run them, and wouldn't need to mark them as not-real

[issue14408] Support ./python -m unittest in the stdlib tests

R. David Murray added the comment: Hmm. OK, I guess we can just disagree on what looks straightforward, and since you are the maintainer of unittest you win :) But unless somebody pronounces, I'll probably keep using the mixin pattern for my own modules. --

[issue14408] Support ./python -m unittest in the stdlib tests

Michael Foord added the comment: Because you then have classes that inherit from object calling methods that clearly don't exist (until you subclass them *and* TestCase). It looks weird and also means the classes can't be tested in isolation. With a class decorator the code would *look* strai

[issue14408] Support ./python -m unittest in the stdlib tests

R. David Murray added the comment: Not particularly elegant? Why not? I find marking tests that should be executed by having them (and only them) inherit from TestCase to fit my sense of what is Pythonic, while having a hidden please-ignore-me attribute doesn't. --

[issue14408] Support ./python -m unittest in the stdlib tests

Michael Foord added the comment: Yes, feel free to create an issue for that. If you provide a patch for it (with tests) I'll review it. The decorator itself can be applied to both TestCase and FunctionTestCase in unittest as well. One implementation would be to apply a private attribute to

[issue14408] Support ./python -m unittest in the stdlib tests

Matt Joiner added the comment: I'm working on a patch using TestCase a la test_queue. Perhaps we should create an issue for a base class test case decorator or something to that effect? -- ___ Python tracker

[issue14408] Support ./python -m unittest in the stdlib tests

Michael Foord added the comment: One way to exclude base classes from being loaded as tests is to have the base class *not* inherit from TestCase (just from object) - and use it as a mixin class for the actual TestCases. This isn't particularly elegant (but works fine). A better way of suppo

[issue14408] Support ./python -m unittest in the stdlib tests

R. David Murray added the comment: It sounds like we just need to fix the TestCase inheritance, like we did in test_queue. We should also look more carefully at the threading setup/cleanup. At some point I think we changed the best-practice idiom to be independent of regrtest, but we probab

[issue14408] Support ./python -m unittest in the stdlib tests

Matt Joiner added the comment: Michael: The thread setup and cleanup is not required, AFAICT. You are also correct in that these particular test modules do not run correctly without modification (although test_queue does now that the bug I reported there was fixed). Sorry by predicated, I me

[issue14408] Support ./python -m unittest in the stdlib tests

R. David Murray added the comment: Right. What I meant to say was "test_main can be converted to use normal unittest test loading". test_email is not an example of that, since it does use test discovery, but is a good example of a test collection that works with both regrtest and unittest w

[issue14408] Support ./python -m unittest in the stdlib tests

Michael Foord added the comment: Test discovery is only needed for finding tests in directories of tests - for a single test module the standard test loader should work fine. -- ___ Python tracker ___

[issue14408] Support ./python -m unittest in the stdlib tests

R. David Murray added the comment: The test_main functions can be converted to use unittest discovery, though. That's what I did for test_email. -- ___ Python tracker ___

[issue14408] Support ./python -m unittest in the stdlib tests

Changes by Éric Araujo : -- title: Support the load_tests protocol in the stdlib tests -> Support ./python -m unittest in the stdlib tests ___ Python tracker ___ ___