[issue8273] move test_support into the unittest package

Raymond Hettinger added the comment: -1 on moving the module into the mainstream without significant reworking and rethinking. This module is a junk collection (I know because I've contributed some it). The unittest module is important. It needs a super clean, well thought out API. The te

[issue8273] move test_support into the unittest package

R. David Murray added the comment: I'm writing unittests for a program I'm writing, and would really love to be able to use captured_stdout/stderr. Of course, I have to support Python 2.5, and can't really justify installing unittest2, so I'll have to roll my own anyway, but I'm definitely +

[issue8273] move test_support into the unittest package

Ezio Melotti added the comment: I agree that some things can be moved in unittest, however several of the function in test_support are designed specifically for being used for the python test suite. For example temp_cwd is something that could be really useful in unittest in my opinion, howev

[issue8273] move test_support into the unittest package

Michael Foord added the comment: I think namespacing utility functions / classes inside unittest is fine (even good), but agree that there needs to be careful thinking about APIs that are made public in this way. To a certain extent this code has already proved its utility, but up until now i

[issue8273] move test_support into the unittest package

Brett Cannon added the comment: I take the blame on documenting the handful of things in test.support; I thought it was a good idea to expose the handful of things that had an actual design to them. =) But yes, we should probably shift to test.support to being private and simply exposing the

[issue8273] move test_support into the unittest package

Michael Foord added the comment: Something like this was discussed at the language summit. Now we have the skip decorators it is easy to skip tests on certain platforms or only run them on certain platforms. The cpython_only decorator is fine - but I'd prefer a general solution rather than i

[issue8273] move test_support into the unittest package

Tarek Ziadé added the comment: about : cpython_only / is_jython I think the idea here is to mark some tests as being specific to some implementations. I remember a discussion where we said that we could add in sys or platform the name of the implementation and make this somehow future-proof.

[issue8273] move test_support into the unittest package

Tim Golden added the comment: On 31/03/2010 14:20, Michael Foord wrote: > - TESTFN > > This is a global for setting the directory temporary files are created in? > Don't think I like the global approach. Which functions is it used by? It's used *all over the place*. I started trying to rip it

[issue8273] move test_support into the unittest package

Michael Foord added the comment: A 'support' sub-module in unittest is ok. I wonder if it is the best name? - is_jython This is too specific and ignores the other implementations. This information is also available from sys / platform modules. -1 - TESTFN This is a global for setting the

[issue8273] move test_support into the unittest package

Tarek Ziadé added the comment: Yes, let's make things explicit as David said: - "test" package: tests for Python itself, with private stuff, undocumented. - "unittest" package: the test framework that is used by the test package and that is public I'd add a support module in unittest, conta

[issue8273] move test_support into the unittest package

Michael Foord added the comment: Sorry, missed David's comment: > Maybe we could move the appropriate stuff and get rid of the > test_support doc page altogether. And when we move stuff to unittest > maybe we could take the opportunity to clean up any warts in the > interfaces. This I agree w

[issue8273] move test_support into the unittest package

Michael Foord added the comment: Right - that is exactly why I want a specific proposal as to which APIs are generally useful and should be considered for moving into unittest. -- ___ Python tracker __

[issue8273] move test_support into the unittest package

Florent Xicluna added the comment: > Maybe we could move the appropriate stuff and get rid of the > test_support doc page altogether. And when we move stuff to unittest > maybe we could take the opportunity to clean up any warts in the > interfaces. +1 I don't like the burden of backward comp

[issue8273] move test_support into the unittest package

R. David Murray added the comment: Actually, the list Terek posted a link to is a public doc page, and as was made clear in the recent issue about the check_warnings helper, we do have to maintain backward compatibility. There (should be) undocumented stuff in test_support, purposely left

[issue8273] move test_support into the unittest package

Michael Foord added the comment: So which parts, can you list the ones you think are most important? At the moment we don't have to maintain backwards compatibility with test.test_support as it isn't a 'public' API - so the cost in adding it to the standard library is the same as adding any c

[issue8273] move test_support into the unittest package

Tarek Ziadé added the comment: Sure, no need to have the test runner parts. -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue8273] move test_support into the unittest package

Michael Foord added the comment: Not all the APIs are appropriate though, for example TestFailed and TestSkipped are not needed. Some of the APIs only make sense for the test_support runner and unittest has its own runner now. I think the proposal needs to be more specific about which APIs yo

[issue8273] move test_support into the unittest package

Tarek Ziadé added the comment: Basically, all the APIs in test_support could live in unittest and the test package could only contain the test modules written for Python. IOW, these tests helpers can help more people than the core devs -- ___ Pytho

[issue8273] move test_support into the unittest package

Michael Foord added the comment: Hmmm... I'm not sure moving everything as is is a good idea. Any parts in particular you want? -- ___ Python tracker ___ ___

[issue8273] move test_support into the unittest package

New submission from Tarek Ziadé : Let's move test_support in unittest ! Then maybe, let's expose some of test_support functions into a new class on the top of unittest.TestCase, so they can be used via methods. The purpose is power up people when it comes to write test fixtures or work in a