<commit_before>=============================================
``kt.testing`` - Test harness support library
=============================================

Applications that make use of large frameworks often need to mock or
stub out portions of those APIs in ways that provide a consistent view
on the resources that API exposes.  A test fixture often wants to
establish a particular state for the API at a higher level than that of
individual API calls; this is especially the case if an API provides
more than one way to do things.  How the code under test uses the
underlying API is less interesting than the information exposed by the
API and the operations performed on it.

There are a number of ways to approach these situations using tests
based on ``unittest.TestCase`` (or similar) fixtures.  Too often, these
become tangled messes where test authors have to pay attention to
implementation details of base and mix-in classes to avoid support for
different APIs interfering with each other's internal state.

This library approaches the problem by allowing APIs that support test
control of other frameworks or libraries to be independent components.
These *fixture components* can:

- access the test object,

- be involved in setup and teardown,

- provide cleanup handlers,

- provide APIs for tests to configure the behavior of the APIs they
  manage, and

- provide additional assertion methods specific to what they do.

These components can inject themselves into the APIs they manage in
whatever ways are appropriate (using ``mock.patch``, for example).


Release history
---------------

1.1.0 (unreleased)
~~~~~~~~~~~~~~~~~~

New features:

- ``kt.testing.requests.Requests`` methods ``add_error`` and
  ``add_response`` grew a new, optional parameter, ``filter``, which
  accepts a callable wit the same signature as ``requests.request``.
  The result is a Boolean value that indicates whether request should be
  considered a match for the response.  The filter function will only be
  called if the method and URL match.

  This can be used to check whether request body matches some
  expectation.  This can be especially valuable for RPC-type interfaces
  (XML-RPC or SOAP, for example).<commit_msg>set release date for 1.1.0<commit_after>=============================================
``kt.testing`` - Test harness support library
=============================================

Applications that make use of large frameworks often need to mock or
stub out portions of those APIs in ways that provide a consistent view
on the resources that API exposes.  A test fixture often wants to
establish a particular state for the API at a higher level than that of
individual API calls; this is especially the case if an API provides
more than one way to do things.  How the code under test uses the
underlying API is less interesting than the information exposed by the
API and the operations performed on it.

There are a number of ways to approach these situations using tests
based on ``unittest.TestCase`` (or similar) fixtures.  Too often, these
become tangled messes where test authors have to pay attention to
implementation details of base and mix-in classes to avoid support for
different APIs interfering with each other's internal state.

This library approaches the problem by allowing APIs that support test
control of other frameworks or libraries to be independent components.
These *fixture components* can:

- access the test object,

- be involved in setup and teardown,

- provide cleanup handlers,

- provide APIs for tests to configure the behavior of the APIs they
  manage, and

- provide additional assertion methods specific to what they do.

These components can inject themselves into the APIs they manage in
whatever ways are appropriate (using ``mock.patch``, for example).


Release history
---------------

1.1.0 (2016-05-10)
~~~~~~~~~~~~~~~~~~

New features:

- ``kt.testing.requests.Requests`` methods ``add_error`` and
  ``add_response`` grew a new, optional parameter, ``filter``, which
  accepts a callable wit the same signature as ``requests.request``.
  The result is a Boolean value that indicates whether request should be
  considered a match for the response.  The filter function will only be
  called if the method and URL match.

  This can be used to check whether request body matches some
  expectation.  This can be especially valuable for RPC-type interfaces
  (XML-RPC or SOAP, for example).
{'fraction_non_alphanumeric': 0.09688270912760709, 'fraction_numerical': 0.0038125140165956493, 'mean_word_length': 4.392986698911729, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6142519', 'n_tokens_mistral': 1071, 'n_tokens_neox': 1005, 'n_words': 633}