Merge lp:~jml/testtools/patch-310770 into lp:~testtools-committers/testtools/trunk
| Status: | Merged |
|---|---|
| Merged at revision: | 89 |
| Proposed branch: | lp:~jml/testtools/patch-310770 |
| Merge into: | lp:~testtools-committers/testtools/trunk |
| Diff against target: | 0 lines |
| To merge this branch: | bzr merge lp:~jml/testtools/patch-310770 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| testtools developers | 2010-08-03 | Pending | |
|
Review via email:
|
|||
Description of the Change
More and more I've found myself wanting to monkey-patch code with testtools in the same way I can for Trial. This branch adds support for just such a thing.
- 89. By Jonathan Lange on 2010-08-03
-
Merge trunk
- 90. By Jonathan Lange on 2010-08-03
-
NEWS.
| Robert Collins (lifeless) wrote : | # |
| Jonathan Lange (jml) wrote : | # |
I don't like that.
We have a really nice monkey-patching module in Twisted and it simply never gets used. The only thing that ends up being used is TestCase.patch.
The delattr thing rarely comes up in actual usage, but I agree that it's a good behaviour to have. Will fix that.
| Robert Collins (lifeless) wrote : | # |
On Wed, Aug 4, 2010 at 10:32 PM, Jonathan Lange <email address hidden> wrote:
> I don't like that.
>
> We have a really nice monkey-patching module in Twisted and it simply never gets used. The only thing that ends up being used is TestCase.patch.
Why does that happen, do you think?
I'd really like others to be able to use this outside of TestCase,
e.g. for fixtures, so I'd _really_ like the core to be
not-on-TestCase, it has no justification to be there; having glue for
it on TestCase I'm ambivalent but not keen on, but ok with as long as
it really is a one-liner.
-Rob
- 91. By Jonathan Lange on 2010-08-04
-
Handle cases where attributes don't exist.
| Jonathan Lange (jml) wrote : | # |
It doesn't happen because the need for it is small, and it's almost always easier to write it yourself than add the import and re-use code.
Still, if you're OK with a TestCase.patch() convenience function I can dredge up the external library I added in previous revisions and make TestCase.patch() a one-liner.
| Robert Collins (lifeless) wrote : | # |
> Still, if you're OK with a TestCase.patch() convenience function I can dredge up the external library I added in previous revisions and make TestCase.patch() a one-liner.
+1
- 92. By Jonathan Lange on 2010-08-04
-
Restore monkey code.
- 93. By Jonathan Lange on 2010-08-04
-
Handle missing attributes better.
- 94. By Jonathan Lange on 2010-08-04
-
Not necessary
- 95. By Jonathan Lange on 2010-08-04
-
Add a convenience function to just patch a single thing.
- 96. By Jonathan Lange on 2010-08-04
-
Make TestCase.patch() use the new patch() helper method. Becomes slightly
less useful but more pure.

A few thoughts.
Firstly, I'd expect this to delete an attribute too, if the original
was unset; this doesn't, but the tests don't make it clear whether
that is oversight or intent.
Secondly, this is so useful, I really would rather not see it on TestCase.
How about
def patch(obj, attribute, value):
"""Set obj.attribute to value and return a cleanup to restore it."""
?
Then you can do (patch( sys, "stderr", StringIO())
self.addCleanup