=============
nti.testing
=============
.. image:: https://img.shields.io/pypi/v/nti.testing.svg
:target: https://pypi.python.org/pypi/nti.testing/
:alt: Latest release
.. image:: https://img.shields.io/pypi/pyversions/nti.testing.svg
:target: https://pypi.org/project/nti.testing/
:alt: Supported Python versions
.. image:: https://github.com/NextThought/nti.testing/actions/workflows/tests.yml/badge.svg
:target: https://github.com/NextThought/nti.testing/actions/workflows/tests.yml
:alt: Test Status
.. image:: https://coveralls.io/repos/github/NextThought/nti.testing/badge.svg
:target: https://coveralls.io/github/NextThought/nti.testing
.. image:: http://readthedocs.org/projects/ntitesting/badge/?version=latest
:target: http://ntitesting.readthedocs.io/en/latest/?badge=latest
:alt: Documentation Status
Support for writing tests, particularly in a Zope3/ZTK environment,
using zope.testing (nose2 may also work, but is not recommended).
Complete documentation is hosted at https://ntitesting.readthedocs.io/
Installation
============
nti.testing can be installed using pip, either from the git repository
or from PyPI::
pip install nti.testing[testgres]
Use the ``testgres`` extra to be able to use `nti.testing.layers.postgres`.
PyHamcrest
==========
nti.testing provides a group of `PyHamcrest`_ matchers. There are both
general-purpose matchers and matchers that are of use to users of
`zope.interface`_ and `zope.schema`_.
.. _PyHamcrest: https://pyhamcrest.readthedocs.io/en/latest/
.. _zope.interface: https://pypi.python.org/pypi/zope.interface
.. _zope.schema: https://pypi.python.org/pypi/zope.schema
.. NOTE: We rely on the Sphinx 'default_role' to turn single back quotes into links,
while still being compatible with rendering with plain docutils/readme_renderer
for PyPI.
Matchers can be imported from the `nti.testing.matchers` module; the most commonly used matchers
can be directly imported from `nti.testing`.
Basic Matchers
--------------
`is_true` and `is_false` check the `bool` value of a supplied
object (we're using literals for explanation purposes, but it
obviously makes more sense, and reads better, when the matched object
is a variable, often of a more complex type):
>>> from hamcrest import assert_that, is_
>>> from nti.testing import is_true, is_false
>>> assert_that("Hi", is_true())
>>> assert_that(0, is_false())
Interface Matchers
------------------
Next we come to matchers that support basic use of ``zope.interface``.
We can check that an object provides an interface and that a factory
implements it:
>>> from zope.interface import Interface, Attribute, implementer
>>> class IThing1(Interface):
... pass
>>> class IThing2(Interface):
... pass
>>> class IThings(IThing1, IThing2):
... got_that_thing_i_sent_you = Attribute("Did you get that thing?")
>>> @implementer(IThings)
... class Thing(object):
... def __repr__(self): return "<object Thing>"
>>> from nti.testing import provides, implements
>>> assert_that(Thing(), provides(IThings))
>>> assert_that(Thing, implements(IThings))
The attentive reader will have noticed that ``IThings`` defines an
attribute that our implementation doesn't *actually* provide. This is
where the next stricter check comes in. `verifiably_provides` uses
the interface machinery to determine that all attributes and methods
specified by the interface are present as described:
>>> from nti.testing import verifiably_provides
>>> assert_that(Thing(), verifiably_provides(IThing2, IThing1))
>>> assert_that(Thing(), verifiably_provides(IThings))
Traceback (most recent call last):
...
AssertionError:...
Expected: object verifiably providing <...IThings>
but: Using class <class 'Thing'> the object <object Thing> has failed to implement interface ....IThings: The ....IThings.got_that_thing_i_sent_you attribute was not provided.
<BLANKLINE>
If multiple attributes or methods are not provided, all such missing
information is reported:
>>> class IThingReceiver(IThings):
... def receive(some_thing):
... """Get the thing"""
>>> @implementer(IThingReceiver)
... class ThingReceiver(object):
... def __repr__(self): return "<object ThingReceiver>"
>>> assert_that(ThingReceiver(), verifiably_provides(IThingReceiver))
Traceback (most recent call last):
...
AssertionError:...
Expected: object verifiably providing <...IThingReceiver>
but: Using class <class 'ThingReceiver'> the object <object ThingReceiver> has failed to implement interface ....IThingReceiver:
The ....IThings.got_that_thing_i_sent_you attribute was not provided
The ....IThingReceiver.receive(some_thing) attribute was not provided
<BLANKLINE>
``zope.interface`` can only check whether or not an attribute or
method is present. To place (arbitrary) tighter constraints on the
values of the attributes, we can step up to ``zope.schema`` and the
`validly_provides` matcher:
>>> from zope.schema import Bool
>>> class IBoolThings(IThing1, IThing2):
... got_that_thing_i_sent_you = Bool(required=True)
>>> @implementer(IBoolThings)
... class BoolThing(object):
... def __repr__(self): return "<object BoolThing>"
`validly_provides` is a superset of `verifiably_provides`:
>>> from nti.testing import validly_provides
>>> assert_that(BoolThing(), validly_provides(IThing1, IThing2))
>>> assert_that(BoolThing(), validly_provides(IBoolThings))
Traceback (most recent call last):
...
AssertionError:...
Expected: (object verifiably providing <...IBoolThings> and object validly providing ....IBoolThings)
but: object verifiably providing <....IBoolThings> Using class <class 'BoolThing'> the object <object BoolThing> has failed to implement interface ....IBoolThings: The ....IBoolThings.got_that_thing_i_sent_you attribute was not provided.
<BLANKLINE>
For finer grained control, we can compare data against schema fields
using `validated_by` and `not_validated_by`:
>>> from nti.testing import validated_by, not_validated_by
>>> field = IBoolThings.get('got_that_thing_i_sent_you')
>>> assert_that(True, is_(validated_by(field)))
>>> assert_that(None, is_(not_validated_by(field)))
Parent/Child Relationships
--------------------------
The `aq_inContextOf` matcher uses the concepts from `Acquisition` to
check parent/child relationships:
>>> from nti.testing import aq_inContextOf
>>> class Parent(object):
... pass
>>> class Child(object):
... __parent__ = None
>>> parent = Parent()
>>> child = Child()
>>> child.__parent__ = parent
>>> assert_that(child, aq_inContextOf(parent))
Test Fixtures
=============
Support for test fixtures can be found in `nti.testing.base` and
`nti.testing.layers`. The ``base`` package includes fully-fleshed
out base classes for direct use, while the ``layers`` package mostly includes
mixins that can be used to construct your own test layers.
The ``base`` package makes a distinction between "normal" and "shared"
fixtures. Normal fixtures are those that are used for a single test
case. They are established via ``setUp`` and torn down via
``tearDown``.
In contrast, shared fixtures are expected to endure for the duration
of all the tests in the class or all the tests in the layer. These are
best used when the fixture is expensive to create. Anything that
extends from `nti.testing.base.AbstractSharedTestBase` creates a shared fixture.
Through the magic of metaclasses, such a subclass can also be assigned
as the ``layer`` property of another class to be used as a test layer
that can be shared across more than one class.
The most important bases are `nti.testing.base.ConfiguringTestBase` and
`nti.testing.base.SharedConfiguringTestBase`. These are both fixtures for
configuring ZCML, either from existing packages or complete file
paths. To use these, subclass them and define class attributes
``set_up_packages`` and (if necessary) ``features``:
>>> from nti.testing.base import ConfiguringTestBase
>>> import zope.security
>>> class MyConfiguringTest(ConfiguringTestBase):
... set_up_packages = (
... 'zope.component', # the default configuration by name
... # a named file in a named package
... ('ftesting.zcml', 'zope.traversing.tests'),
... # an imported module
... zope.security,
... # Our own package; in a test, this will mean the parent
... # package
... ".")
We would then proceed to write our test methods. The packages that we
specified will be set up and torn down around every test method. In
addition, the ``zope.testing`` cleanup functions will also run around
every test method.
Time
====
Having a clock that's guaranteed to move in a positive increasing way
in every call to ``time.time`` is useful. `nti.testing.time`
provides a decorator to accomplish this that ensures values always are
at least the current time and always are increasing. (It is not thread
safe.) It can be applied to functions or methods, and optionally takes
a ``granularity`` argument:
>>> from nti.testing import time_monotonically_increases
>>> from nti.testing.time import reset_monotonic_time
>>> @time_monotonically_increases(0.1) # increment by 0.1
... def test():
... import time
... t1 = time.time()
... t2 = time.time()
... assert t2 == t1 + 0.1, (t2, t1)
>>> test()
And The Rest
============
There are some other assorted utilities, including support for working with
ZODB in `nti.testing.zodb`. See the API documentation for details.
=========
Changes
=========
4.0.0 (2023-10-24)
==================
- Add support for Python 3.10, 3.11 and 3.12.
- Drop support for Python 2 and Python 3.6 and 3.7.
- Add a layer for working with a ``testgres`` Postgres instance.
- Add methods to the test base classes to support ``unittest.mock`` patches.
3.1.0 (2021-09-08)
==================
- Add support for Python 3.9.
- Drop support for Python 3.5.
- Add the module alias ``nti.testing.mock``, which is either the
standard library ``unittest.mock``, or the backport ``mock``. This
allows easy imports when backwards compatibility matters.
- Make ``mock``, ``mock.Mock`` and various other API attributes,
like ``is_true``, available directly from the ``nti.testing`` namespace.
3.0.0 (2020-06-16)
==================
- Add support for Python 3.8.
- Require zope.interface 5.1. This lets the interface matchers produce
much more informative error messages.
- Add ``nti.testing.zodb`` with helpers for dealing with ZODB. This
makes ZODB 5.6 or above a required dependency.
2.2.1 (2019-09-10)
==================
- Make transaction cleanup safer if the default transaction manager
has been made explicit.
Also, reset the default transaction manager to implicit.
See `issue 17 <https://github.com/NextThought/nti.testing/issues/17>`_.
2.2.0 (2018-08-24)
==================
- Add support for Python 3.7.
- Make ``time_monotonically_increases`` also handle ``time.gmtime``
and add a helper for using it in layers.
2.1.0 (2017-10-23)
==================
- Make ``Acquisition`` an optional dependency. If it is not installed,
the ``aq_inContextOf`` matcher will always return False.
- Remove dependency on ``fudge``. Instead, we now use ``unittest.mock`` on
Python 3, or its backport ``mock`` on Python 2. See `issue 11
<https://github.com/NextThought/nti.testing/issues/11>`_.
- Refactor ZCML configuration support to share more code and
documentation. See `issue 10
<https://github.com/NextThought/nti.testing/issues/10>`_.
- The layer ``ConfiguringLayerMixin`` and the base class
``SharedConfiguringTestBase`` now default to running
configuration in the package the subclass is defined in, just as
subclasses of ``ConfiguringTestBase`` did.
2.0.1 (2017-10-18)
==================
- The validation matchers (``validated_by`` and ``not_validated_by``)
now consider it a failure (by default) if the validate method raises
anything other than ``zope.interface.exceptions.Invalid`` (which
includes the ``zope.schema`` exceptions like ``WrongType``).
Previously, they accepted any exception as meaning the object was
invalid, but this could hide bugs in the actual validation method
itself. You can supply the ``invalid`` argument to the matchers to
loosen or tighten this as desired. (Giving ``invalid=Exception``
will restore the old behaviour.)
See `issue 7 <https://github.com/NextThought/nti.testing/issues/7>`_.
2.0.0 (2017-04-12)
==================
- Add support for Python 3.6.
- Remove ``unicode_literals``.
- Substantially rework ``time_monotonically_increases`` for greater
safety. Fixes `issue 5 <https://github.com/NextThought/nti.testing/issues/5>`_.
1.0.0 (2016-07-28)
==================
- Add Python 3 support.
- Initial PyPI release.
Raw data
{
"_id": null,
"home_page": "https://github.com/OpenNTI/nti.testing",
"name": "nti.testing",
"maintainer": "",
"docs_url": null,
"requires_python": ">=3.8",
"maintainer_email": "",
"keywords": "nose2 testing zope3 ZTK hamcrest",
"author": "Jason Madden",
"author_email": "jason@nextthought.com",
"download_url": "https://files.pythonhosted.org/packages/6d/32/755de8f8c8aef9312c4934561fe14380dcbdefbb2b44b8c849f7c98d0320/nti.testing-4.0.0.tar.gz",
"platform": null,
"description": "=============\n nti.testing\n=============\n\n.. image:: https://img.shields.io/pypi/v/nti.testing.svg\n :target: https://pypi.python.org/pypi/nti.testing/\n :alt: Latest release\n\n.. image:: https://img.shields.io/pypi/pyversions/nti.testing.svg\n :target: https://pypi.org/project/nti.testing/\n :alt: Supported Python versions\n\n.. image:: https://github.com/NextThought/nti.testing/actions/workflows/tests.yml/badge.svg\n :target: https://github.com/NextThought/nti.testing/actions/workflows/tests.yml\n :alt: Test Status\n\n.. image:: https://coveralls.io/repos/github/NextThought/nti.testing/badge.svg\n :target: https://coveralls.io/github/NextThought/nti.testing\n\n.. image:: http://readthedocs.org/projects/ntitesting/badge/?version=latest\n :target: http://ntitesting.readthedocs.io/en/latest/?badge=latest\n :alt: Documentation Status\n\nSupport for writing tests, particularly in a Zope3/ZTK environment,\nusing zope.testing (nose2 may also work, but is not recommended).\n\nComplete documentation is hosted at https://ntitesting.readthedocs.io/\n\nInstallation\n============\n\nnti.testing can be installed using pip, either from the git repository\nor from PyPI::\n\n pip install nti.testing[testgres]\n\nUse the ``testgres`` extra to be able to use `nti.testing.layers.postgres`.\n\nPyHamcrest\n==========\n\nnti.testing provides a group of `PyHamcrest`_ matchers. There are both\ngeneral-purpose matchers and matchers that are of use to users of\n`zope.interface`_ and `zope.schema`_.\n\n\n.. _PyHamcrest: https://pyhamcrest.readthedocs.io/en/latest/\n.. _zope.interface: https://pypi.python.org/pypi/zope.interface\n.. _zope.schema: https://pypi.python.org/pypi/zope.schema\n\n.. NOTE: We rely on the Sphinx 'default_role' to turn single back quotes into links,\n while still being compatible with rendering with plain docutils/readme_renderer\n for PyPI.\n\nMatchers can be imported from the `nti.testing.matchers` module; the most commonly used matchers\ncan be directly imported from `nti.testing`.\n\nBasic Matchers\n--------------\n\n`is_true` and `is_false` check the `bool` value of a supplied\nobject (we're using literals for explanation purposes, but it\nobviously makes more sense, and reads better, when the matched object\nis a variable, often of a more complex type):\n\n >>> from hamcrest import assert_that, is_\n >>> from nti.testing import is_true, is_false\n >>> assert_that(\"Hi\", is_true())\n >>> assert_that(0, is_false())\n\nInterface Matchers\n------------------\n\nNext we come to matchers that support basic use of ``zope.interface``.\n\nWe can check that an object provides an interface and that a factory\nimplements it:\n\n >>> from zope.interface import Interface, Attribute, implementer\n >>> class IThing1(Interface):\n ... pass\n >>> class IThing2(Interface):\n ... pass\n >>> class IThings(IThing1, IThing2):\n ... got_that_thing_i_sent_you = Attribute(\"Did you get that thing?\")\n >>> @implementer(IThings)\n ... class Thing(object):\n ... def __repr__(self): return \"<object Thing>\"\n\n >>> from nti.testing import provides, implements\n >>> assert_that(Thing(), provides(IThings))\n >>> assert_that(Thing, implements(IThings))\n\nThe attentive reader will have noticed that ``IThings`` defines an\nattribute that our implementation doesn't *actually* provide. This is\nwhere the next stricter check comes in. `verifiably_provides` uses\nthe interface machinery to determine that all attributes and methods\nspecified by the interface are present as described:\n\n >>> from nti.testing import verifiably_provides\n >>> assert_that(Thing(), verifiably_provides(IThing2, IThing1))\n >>> assert_that(Thing(), verifiably_provides(IThings))\n Traceback (most recent call last):\n ...\n AssertionError:...\n Expected: object verifiably providing <...IThings>\n but: Using class <class 'Thing'> the object <object Thing> has failed to implement interface ....IThings: The ....IThings.got_that_thing_i_sent_you attribute was not provided.\n <BLANKLINE>\n\nIf multiple attributes or methods are not provided, all such missing\ninformation is reported:\n\n >>> class IThingReceiver(IThings):\n ... def receive(some_thing):\n ... \"\"\"Get the thing\"\"\"\n >>> @implementer(IThingReceiver)\n ... class ThingReceiver(object):\n ... def __repr__(self): return \"<object ThingReceiver>\"\n >>> assert_that(ThingReceiver(), verifiably_provides(IThingReceiver))\n Traceback (most recent call last):\n ...\n AssertionError:...\n Expected: object verifiably providing <...IThingReceiver>\n but: Using class <class 'ThingReceiver'> the object <object ThingReceiver> has failed to implement interface ....IThingReceiver:\n The ....IThings.got_that_thing_i_sent_you attribute was not provided\n The ....IThingReceiver.receive(some_thing) attribute was not provided\n <BLANKLINE>\n\n``zope.interface`` can only check whether or not an attribute or\nmethod is present. To place (arbitrary) tighter constraints on the\nvalues of the attributes, we can step up to ``zope.schema`` and the\n`validly_provides` matcher:\n\n >>> from zope.schema import Bool\n >>> class IBoolThings(IThing1, IThing2):\n ... got_that_thing_i_sent_you = Bool(required=True)\n >>> @implementer(IBoolThings)\n ... class BoolThing(object):\n ... def __repr__(self): return \"<object BoolThing>\"\n\n`validly_provides` is a superset of `verifiably_provides`:\n\n >>> from nti.testing import validly_provides\n >>> assert_that(BoolThing(), validly_provides(IThing1, IThing2))\n >>> assert_that(BoolThing(), validly_provides(IBoolThings))\n Traceback (most recent call last):\n ...\n AssertionError:...\n Expected: (object verifiably providing <...IBoolThings> and object validly providing ....IBoolThings)\n but: object verifiably providing <....IBoolThings> Using class <class 'BoolThing'> the object <object BoolThing> has failed to implement interface ....IBoolThings: The ....IBoolThings.got_that_thing_i_sent_you attribute was not provided.\n <BLANKLINE>\n\nFor finer grained control, we can compare data against schema fields\nusing `validated_by` and `not_validated_by`:\n\n >>> from nti.testing import validated_by, not_validated_by\n >>> field = IBoolThings.get('got_that_thing_i_sent_you')\n >>> assert_that(True, is_(validated_by(field)))\n >>> assert_that(None, is_(not_validated_by(field)))\n\nParent/Child Relationships\n--------------------------\n\nThe `aq_inContextOf` matcher uses the concepts from `Acquisition` to\ncheck parent/child relationships:\n\n >>> from nti.testing import aq_inContextOf\n >>> class Parent(object):\n ... pass\n >>> class Child(object):\n ... __parent__ = None\n >>> parent = Parent()\n >>> child = Child()\n >>> child.__parent__ = parent\n\n >>> assert_that(child, aq_inContextOf(parent))\n\nTest Fixtures\n=============\n\nSupport for test fixtures can be found in `nti.testing.base` and\n`nti.testing.layers`. The ``base`` package includes fully-fleshed\nout base classes for direct use, while the ``layers`` package mostly includes\nmixins that can be used to construct your own test layers.\n\nThe ``base`` package makes a distinction between \"normal\" and \"shared\"\nfixtures. Normal fixtures are those that are used for a single test\ncase. They are established via ``setUp`` and torn down via\n``tearDown``.\n\nIn contrast, shared fixtures are expected to endure for the duration\nof all the tests in the class or all the tests in the layer. These are\nbest used when the fixture is expensive to create. Anything that\nextends from `nti.testing.base.AbstractSharedTestBase` creates a shared fixture.\nThrough the magic of metaclasses, such a subclass can also be assigned\nas the ``layer`` property of another class to be used as a test layer\nthat can be shared across more than one class.\n\nThe most important bases are `nti.testing.base.ConfiguringTestBase` and\n`nti.testing.base.SharedConfiguringTestBase`. These are both fixtures for\nconfiguring ZCML, either from existing packages or complete file\npaths. To use these, subclass them and define class attributes\n``set_up_packages`` and (if necessary) ``features``:\n\n >>> from nti.testing.base import ConfiguringTestBase\n >>> import zope.security\n >>> class MyConfiguringTest(ConfiguringTestBase):\n ... set_up_packages = (\n ... 'zope.component', # the default configuration by name\n ... # a named file in a named package\n ... ('ftesting.zcml', 'zope.traversing.tests'),\n ... # an imported module\n ... zope.security,\n ... # Our own package; in a test, this will mean the parent\n ... # package\n ... \".\")\n\nWe would then proceed to write our test methods. The packages that we\nspecified will be set up and torn down around every test method. In\naddition, the ``zope.testing`` cleanup functions will also run around\nevery test method.\n\nTime\n====\n\nHaving a clock that's guaranteed to move in a positive increasing way\nin every call to ``time.time`` is useful. `nti.testing.time`\nprovides a decorator to accomplish this that ensures values always are\nat least the current time and always are increasing. (It is not thread\nsafe.) It can be applied to functions or methods, and optionally takes\na ``granularity`` argument:\n\n >>> from nti.testing import time_monotonically_increases\n >>> from nti.testing.time import reset_monotonic_time\n >>> @time_monotonically_increases(0.1) # increment by 0.1\n ... def test():\n ... import time\n ... t1 = time.time()\n ... t2 = time.time()\n ... assert t2 == t1 + 0.1, (t2, t1)\n\n >>> test()\n\nAnd The Rest\n============\n\nThere are some other assorted utilities, including support for working with\nZODB in `nti.testing.zodb`. See the API documentation for details.\n\n\n=========\n Changes\n=========\n\n4.0.0 (2023-10-24)\n==================\n\n- Add support for Python 3.10, 3.11 and 3.12.\n- Drop support for Python 2 and Python 3.6 and 3.7.\n- Add a layer for working with a ``testgres`` Postgres instance.\n- Add methods to the test base classes to support ``unittest.mock`` patches.\n\n\n3.1.0 (2021-09-08)\n==================\n\n- Add support for Python 3.9.\n\n- Drop support for Python 3.5.\n\n- Add the module alias ``nti.testing.mock``, which is either the\n standard library ``unittest.mock``, or the backport ``mock``. This\n allows easy imports when backwards compatibility matters.\n\n- Make ``mock``, ``mock.Mock`` and various other API attributes,\n like ``is_true``, available directly from the ``nti.testing`` namespace.\n\n3.0.0 (2020-06-16)\n==================\n\n- Add support for Python 3.8.\n\n- Require zope.interface 5.1. This lets the interface matchers produce\n much more informative error messages.\n\n- Add ``nti.testing.zodb`` with helpers for dealing with ZODB. This\n makes ZODB 5.6 or above a required dependency.\n\n2.2.1 (2019-09-10)\n==================\n\n- Make transaction cleanup safer if the default transaction manager\n has been made explicit.\n\n Also, reset the default transaction manager to implicit.\n\n See `issue 17 <https://github.com/NextThought/nti.testing/issues/17>`_.\n\n\n2.2.0 (2018-08-24)\n==================\n\n- Add support for Python 3.7.\n\n- Make ``time_monotonically_increases`` also handle ``time.gmtime``\n and add a helper for using it in layers.\n\n\n2.1.0 (2017-10-23)\n==================\n\n- Make ``Acquisition`` an optional dependency. If it is not installed,\n the ``aq_inContextOf`` matcher will always return False.\n\n- Remove dependency on ``fudge``. Instead, we now use ``unittest.mock`` on\n Python 3, or its backport ``mock`` on Python 2. See `issue 11\n <https://github.com/NextThought/nti.testing/issues/11>`_.\n\n- Refactor ZCML configuration support to share more code and\n documentation. See `issue 10\n <https://github.com/NextThought/nti.testing/issues/10>`_.\n\n- The layer ``ConfiguringLayerMixin`` and the base class\n ``SharedConfiguringTestBase`` now default to running\n configuration in the package the subclass is defined in, just as\n subclasses of ``ConfiguringTestBase`` did.\n\n2.0.1 (2017-10-18)\n==================\n\n- The validation matchers (``validated_by`` and ``not_validated_by``)\n now consider it a failure (by default) if the validate method raises\n anything other than ``zope.interface.exceptions.Invalid`` (which\n includes the ``zope.schema`` exceptions like ``WrongType``).\n Previously, they accepted any exception as meaning the object was\n invalid, but this could hide bugs in the actual validation method\n itself. You can supply the ``invalid`` argument to the matchers to\n loosen or tighten this as desired. (Giving ``invalid=Exception``\n will restore the old behaviour.)\n See `issue 7 <https://github.com/NextThought/nti.testing/issues/7>`_.\n\n\n2.0.0 (2017-04-12)\n==================\n\n- Add support for Python 3.6.\n\n- Remove ``unicode_literals``.\n\n- Substantially rework ``time_monotonically_increases`` for greater\n safety. Fixes `issue 5 <https://github.com/NextThought/nti.testing/issues/5>`_.\n\n1.0.0 (2016-07-28)\n==================\n\n- Add Python 3 support.\n\n- Initial PyPI release.\n",
"bugtrack_url": null,
"license": "Apache",
"summary": "Support for testing code",
"version": "4.0.0",
"project_urls": {
"Documentation": "https://ntitesting.readthedocs.io/en/latest/",
"Homepage": "https://github.com/OpenNTI/nti.testing"
},
"split_keywords": [
"nose2",
"testing",
"zope3",
"ztk",
"hamcrest"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "490e1b8db717ebf88a0b12ece15f823519c513c8d0248e6084cf8d6e18126f43",
"md5": "2c277a78b9d1ea5217303db8ccef35c5",
"sha256": "865fad6753c6c453ae723198b48547d6e1d1b7568206714f62b0043132452925"
},
"downloads": -1,
"filename": "nti.testing-4.0.0-py2.py3-none-any.whl",
"has_sig": false,
"md5_digest": "2c277a78b9d1ea5217303db8ccef35c5",
"packagetype": "bdist_wheel",
"python_version": "py2.py3",
"requires_python": ">=3.8",
"size": 44927,
"upload_time": "2023-10-24T17:54:08",
"upload_time_iso_8601": "2023-10-24T17:54:08.564131Z",
"url": "https://files.pythonhosted.org/packages/49/0e/1b8db717ebf88a0b12ece15f823519c513c8d0248e6084cf8d6e18126f43/nti.testing-4.0.0-py2.py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "6d32755de8f8c8aef9312c4934561fe14380dcbdefbb2b44b8c849f7c98d0320",
"md5": "219f0a8fc8b78038b13599ab6f5e0389",
"sha256": "81f0a3941519a632fdab341e953d405b47310ee3d47f2fba1f3c7bca7d51dd41"
},
"downloads": -1,
"filename": "nti.testing-4.0.0.tar.gz",
"has_sig": false,
"md5_digest": "219f0a8fc8b78038b13599ab6f5e0389",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.8",
"size": 53219,
"upload_time": "2023-10-24T17:54:11",
"upload_time_iso_8601": "2023-10-24T17:54:11.178601Z",
"url": "https://files.pythonhosted.org/packages/6d/32/755de8f8c8aef9312c4934561fe14380dcbdefbb2b44b8c849f7c98d0320/nti.testing-4.0.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-10-24 17:54:11",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "OpenNTI",
"github_project": "nti.testing",
"travis_ci": true,
"coveralls": true,
"github_actions": true,
"tox": true,
"lcname": "nti.testing"
}
JSON
