| ==================================== | |
| 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 ([email protected]) | |
| <http://lists.idyll.org/listinfo/testing-in-python>`_ | |
| :Issue tracker: `GitHub Issues | |
| <https://github.com/testing-cabal/mock/issues>`_ | |
| :Last sync: cb6aab1248c4aec4dd578bea717854505a6fb55d | |
| .. _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.7 and 3.3 and up. | |
| * Python 2.6 is supported by mock 2.0.0 and below. | |
| * Python 3.2 is supported by mock 1.3.0 and below - with pip no longer | |
| supporting 3.2, we cannot test against that version anymore. | |
| 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. | |
| Version 2.0.0 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.7, 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. |