Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
F
fuchsia.googlesource.com-third_party-python-testing-cabal-mock
Manage
Activity
Members
Code
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Deploy
Releases
Model registry
Analyze
Contributor analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
fuchsia-mirror
fuchsia.googlesource.com-third_party-python-testing-cabal-mock
Commits
c1ffe144
Commit
c1ffe144
authored
14 years ago
by
Michael Foord
Browse files
Options
Downloads
Patches
Plain Diff
Docs update
parent
6d1ebb3b
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
docs/patch.txt
+23
-2
23 additions, 2 deletions
docs/patch.txt
with
23 additions
and
2 deletions
docs/patch.txt
+
23
−
2
View file @
c1ffe144
...
...
@@ -273,8 +273,6 @@ function; *every* patching will appear in the tuple after "as":
Where to patch
==============
`patch` works by (temporarily) changing the object that a *name* points to with
another one. There can be many names pointing to any individual object, so
for patching to work you must ensure that you patch the name used by the system
...
...
@@ -284,6 +282,29 @@ The basic principle is that you patch where an object is *used*, which is not
necessarily the same place as where it is defined. A couple of examples will
help to clarify this.
Imagine we have a project that we want to test with the following structure::
a.py
-> Defines SomeClass
b.py
-> from a import SomeClass
-> some_function instantiates SomeClass
Now we want to test `some_function` but we want to mock out `SomeClass` using
`patch`. The problem is that when we import module b, which we will have to
do then it imports `SomeClass` from module a. If we use `patch` to mock out
`a.SomeClass` then it will have no effect on our test; module b already has a
reference to the *real* `SomeClass` and it looks like our patching had no
effect.
The key is to patch out `SomeClass` where it is used (or where it is looked up
). In this case `some_function` will actually look up `SomeClass` in module b,
where we have imported it. The patching should look like:
``@patch('b.SomeClass')``
However, consider the alternative scenario where
Patching Descriptors and Proxy Objects
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment