/usr/lib/python2.7/dist-packages/dingus-0.3.4.egg-info/PKG-INFO is in python-dingus 0.3.4-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 | Metadata-Version: 1.1
Name: dingus
Version: 0.3.4
Summary: A record-then-assert mocking library
Home-page: https://github.com/garybernhardt/dingus
Author: Gary Bernhardt
Author-email: gary.bernhardt@gmail.com
License: MIT
Description: ========
DINGUSES
========
A dingus is sort of like a mock object. The main difference is that you don't
set up expectations ahead of time. You just run your code, using a dingus in
place of another object or class, and it will record what happens to it. Then,
once your code has been exercised, you can make assertions about what it did
to the dingus.
A new dingus is created from the Dingus class. You can give dinguses names,
which helps with debugging your tests, especially when there are multiple
dinguses in play.
>>> from dingus import Dingus
>>> d = Dingus('root')
>>> d
<Dingus root>
Accessing any attribute of a dingus will return a new dingus.
>>> d.something
<Dingus root.something>
There are a few exceptions for special dingus methods. We'll see some in a
bit.
A dingus can also be called like a function or method. It doesn't care how
many arguments you give it or what those arguments are. Calls to a dingus will
always return the same object, regardless of the arguments.
>>> d()
<Dingus root()>
>>> d('argument')
<Dingus root()>
>>> d(55)
<Dingus root()>
========================
RECORDING AND ASSERTIONS
========================
At any time we can get a list of calls that have been made to a dingus. Each
entry in the call list contains:
* the name of the method called (or "()" if the dingus itself was called)
* The arguments, or () if none
* The keyword argumnets, or {} if none
* The value that was returned to the caller
Here is a list of the calls we've made to d so far:
>>> from pprint import pprint
>>> pprint(d.calls)
[('()', (), {}, <Dingus root()>),
('()', ('argument',), {}, <Dingus root()>),
('()', (55,), {}, <Dingus root()>)]
You can filter calls by name, arguments, and keyword arguments:
>>> pprint(d.calls('()', 55))
[('()', (55,), {}, <Dingus root()>)]
If you don't care about a particular argument's value, you can use the value
DontCare when filtering:
>>> from dingus import DontCare
>>> pprint(d.calls('()', DontCare))
[('()', ('argument',), {}, <Dingus root()>),
('()', (55,), {}, <Dingus root()>)]
Dinguses can do more than just have attributes accessed and be called. They
support many Python operators. The goal is to allow, and record, any
interaction:
>>> d = Dingus('root')
>>> (2 ** d.something)['hello']() / 100 * 'foo'
<Dingus root.something.__rpow__[hello]().__div__.__mul__>
(Hopefully your real-world dingus recordings won't look like this!)
========
PATCHING
========
Dingus provides a context manager for patching objects during tests. For
example:
>>> from dingus import patch
>>> import urllib2
>>> with patch('urllib2.urlopen'):
... print urllib2.urlopen.__class__
<class 'dingus.Dingus'>
>>> print urllib2.urlopen.__class__
<type 'function'>
You can also use this as a decorator on your test methods:
>>> @patch('urllib2.urlopen')
... def test_something(self):
... pass
...
=========
ISOLATION
=========
The opposite of patch is isolate. It patches everything except the named object:
>>> from dingus import isolate
>>> @isolate('urllib2.urlparse')
... def test_urlparse(self):
... pass
...
When this test runs, everything in the urllib2 module except urlparse will be a
dingus. Note that this may be slow to execute if the module contains many
objects; performance patches are welcome. :)
===============
DANGEROUS MAGIC
===============
Dingus can also automatically replace a module's globals when running tests.
This allows you to write fully isolated unit tests. See
examples/urllib2/test\_urllib2.py for an example. The author no longer
recommends this feature, as it can encourage very brittle tests. You should
feel the pain of manually mocking dependencies; the pain will tell you when a
class collaborates with too many others.
Keywords: testing test mocking mock double stub fake record assert
Platform: UNKNOWN
Classifier: Development Status :: 4 - Beta
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python
Classifier: Topic :: Software Development :: Testing
|