summaryrefslogtreecommitdiff
path: root/docs/index.txt
blob: cbdc7a4a8c1325eebd3682b8e215ffeb32af73ae (plain)
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
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
====================================
 Mock - Mocking and Testing Library
====================================

:Version: |release|
:Date: |today|
:Homepage: `Mock Homepage`_
:Download: `Mock on PyPI`_
:Documentation: `Python Docs`_
:License: `BSD License`_
:Support: `Mailing list (testing-in-python@lists.idyll.org)
 <http://lists.idyll.org/listinfo/testing-in-python>`_
:Issue tracker: `Github Issues
 <https://github.com/testing-cabal/mock/issues>`_
:Last sync: 3f409f756b7b8f75c4543b2c31566bd8b8dbb3dd

.. _Mock Homepage: https://github.com/testing-cabal/mock
.. _BSD License: http://github.com/testing-cabal/mock/blob/master/LICENSE.txt
.. _Python Docs: https://docs.python.org/dev/library/unittest.mock.html

.. module:: mock
   :synopsis: Mock object and testing library.

.. index:: introduction

TOC
+++

.. toctree::
   :maxdepth: 2

   changelog

Introduction
++++++++++++

mock is a library for testing in Python. It allows you to replace parts of
your system under test with mock objects and make assertions about how they
have been used.

mock is now part of the Python standard library, available as
``unittest.mock`` in Python 3.3 onwards. However, if you are writing code that
runs on multiple versions of Python the ``mock`` package is better, as you get
the newest features from the latest release of Python available for all
Pythons.

The ``mock`` package contains a rolling backport of the standard library mock
code compatible with Python 2.6 and up, and 3.2 and up.

Please see the standard library documentation for usage details.

.. index:: installing
.. _installing:

Installing
++++++++++

The current version is |release|. Mock is stable and widely used.

* `mock on PyPI <http://pypi.python.org/pypi/mock>`_

.. index:: repository
.. index:: git

You can checkout the latest development version from Github
repository with the following command:

    ``git clone https://github.com/testing-cabal/mock``


.. index:: pip

You can install mock with pip:

    | ``pip install -U mock``

Alternatively you can download the mock distribution from PyPI and after
unpacking run:

   ``python setup.py install``


.. index:: bug reports

Bug Reports
+++++++++++

Mock uses `unittest2 <http://pypi.python.org/pypi/unittest2>`_ for its own
Issues with the backport process, such as compatibility with a particular
Python, should be reported to the `bug tracker
<https://github.com/testing-cabal/mock/issues>`_. Feature requests and issues
with Mock functionality should be reported to the `Python bug tracker
<https://bugs.python.org>`_.

.. index:: python changes

Python Changes
++++++++++++++

Python NEWS entries from cPython:

.. include:: ../NEWS

.. index:: older versions

Older Versions of Python
++++++++++++++++++++++++

Version 1.0.1 is the last version compatible with Python < 2.6.

.. index:: maintainer notes

Maintainer Notes
++++++++++++++++

Development
===========

Checkout from git (see :ref:`installing`) and submit pull requests.

Committers can just push as desired: since all semantic development takes
place in cPython, the backport process is as lightweight as we can make it.

mock is CI tested using Travis-CI on Python versions 2.6, 2.7, 3.2, 3.3, 3.4,
3.5, nightly Python 3 builds, pypy, pypy3. Jython support is desired, if
someone could contribute a patch to .travis.yml to support it that would be
excellent.

Releasing
=========

NB: please use semver. Bump the major component on API breaks, minor on all
non-bugfix changes, patch on bugfix only changes.

1. tag -s, push --tags origin master
2. setup.py sdist bdist_wheel upload -s


Backporting rules
=================

isinstance checks in cPython to ``type`` need to check ``ClassTypes``.
Code calling ``obj.isidentifier`` needs to change to ``_isidentifier(obj)``.

Backporting process
===================

1. Patch your git am with `my patch <https://github.com/rbtcollins/git>`_.
2. Install the applypatch-transform hook from tools/ to your .git hooks dir.
3. Configure a pre-applypatch hook to test at least all the cPython versions
   we support on each patch that is applied. I use containers, and a sample
   script is in tools/pre-applypatch.
4. Pull down the cPython git mirror: https://github.com/python/cpython.git
5. Export the new revisions since the ``Last sync`` at the top of this
   document::

     revs=${lastsync}
     rm migrate-export
     git log --pretty="format:%H " $revs.. -- Lib/unittest/mock.py \
       Lib/unittest/test/testmock/ > migrate-revs
     tac migrate-revs > migrate-sorted-revs
     for rev in $(< migrate-sorted-revs); do
           git format-patch -1 $rev -k --stdout >> migrate-export;
           done
     echo NEW SYNC POINT: $(git rev-parse HEAD)

6. Import into mock::

     git am -k --reject $path-to-cpython/migrate-export

   This will transform the patches automatically. Currently it will error
   on every NEWS change as I haven't gotten around to making those patches
   automatic. Fixup any errors that occur. When the patch is ready, do a ``git
   add -u`` to update the index and then ``git am --continue`` to move onto
   the next patch. If the patch is inappropriate e.g. the patch removing
   __ne__ which would break older pythons, then either do ``git reset --hard;
   git am --skip`` to discard any partially applied changes and skip over it,
   or, if it has a NEWS entry thats worth preserving, edit it down to just
   that, with a note such as we have for the ``__ne__`` patch, and continue on
   from there.

   The goal is that every patch work at all times.

7. After the import is complete, update this document with the new sync point.

8. Push to a personal branch and propose a PR to the main repo. This will make
   Travis-CI test it. If it works, push to the main repo.