| msg62627 - (view) |
Author: Virgil Dupras (vdupras)  |
Date: 2008-02-21 16:11 |
| I've been using unittest for quite a while. One thing I got tired with is the code duplication for file management and mocking. A few months ago I created this nifty little TestCase subclass and I've been using it ever since. It works quite well. Am I the only one to extensively use temporary files and mocking in my tests? If not, I would suggest integrating my little subclass to unittest.Testcase, or if people think these functionalities out-scope unittest.TestCase, maybe we could put it in a separate unit. Here's the unit I have here. |
|
|
| msg62643 - (view) |
Author: Benjamin Peterson (benjamin.peterson) *  |
Date: 2008-02-21 19:52 |
| First, is hs a company package? You'll most likely want to remove it. Otherwise, this looks useful. I wonder if this is something we could use in test.test_support. I'd like it for some of Python's regression tests. Brett, what do you think about that? |
|
|
| msg62646 - (view) |
Author: Virgil Dupras (vdupras) |
Date: 2008-02-21 19:56 |
| Well, yeah, but I'm the owner, it's not like if the copyright was a problem. I'd gladly release it (and the test unit that goes with it) under BSD. |
|
|
| msg62647 - (view) |
Author: Virgil Dupras (vdupras) |
Date: 2008-02-21 19:59 |
| Oh, you meant hs.path? ah yeah, it's just for tmppath(), which is of no use except in my own stuff. |
|
|
| msg62649 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2008-02-21 20:01 |
| The Path class of hs.path is, I assume, a nice wrapper around a file or directory. However, Python does not have something like this, so it's probably more useful to just return the raw path. |
|
|
| msg62662 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2008-02-21 21:38 |
| -1 on adding these to unittest. The module is already too complex. Mock objects have been rejected previously and the rationale still holds. There is no standardized approach that meets everyone's needs. It doesn't make sense to lock in one of the many ways of doing it. The tmpdir() method also locks-in one of many approaches. I recommend against both additions. |
|
|
| msg62666 - (view) |
Author: Steve Purcell (purcell) |
Date: 2008-02-21 22:50 |
| I agree with Raymond: -1 from me. There isn't a consensus on what "mock object" means*, and trying to provide a standardised mock object facility is a quagmire*, hence the prior rejections to which Raymond refers. It's easy to roll your own simple mock objects as needed, e.g. for whichever Python regression tests might need them. * Note, for instance, that mock object libraries variously provide support for record/playback of calls, partial replacement of methods in existing classes or instances, and subtle distinctions between "stubs" and "mocks". I'm aware of at least three wildly different yet equally popular mock object libraries in the Java world, each with its own uniquely opinionated user base. |
|
|