Skip to content

DOC: Demo incorporating pytest into test classes #15989

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 13, 2017
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file modified doc/source/_static/ci.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
33 changes: 22 additions & 11 deletions doc/source/contributing.rst
Original file line number Diff line number Diff line change
Expand Up @@ -614,23 +614,34 @@ the expected correct result::

assert_frame_equal(pivoted, expected)

How to use ``parametrize``
~~~~~~~~~~~~~~~~~~~~~~~~~~
Transitioning to ``pytest``
~~~~~~~~~~~~~~~~~~~~~~~~~~~

`pytest <http://doc.pytest.org/en/latest/>`__ has a nice feature `parametrize <https://docs.pytest.org/en/latest/parametrize.html>`__ to allow
testing of many cases in a concise way that enables an easy-to-read syntax.
*pandas* existing test structure is *mostly* classed based, meaning that you will typically find tests wrapped in a class, inheriting from ``tm.TestCase``.

.. note::
.. code-block:: python

class TestReallyCoolFeature(tm.TestCase):
....

*pandas* existing test structure is *mostly* classed based, meaning that you will typically find tests wrapped in a class, inheriting from ``tm.TestCase``.
Going forward, we are moving to a more *functional* style using the `pytest <http://doc.pytest.org/en/latest/>`__ framework, which offers a richer testing
framework that will facilitate testing and developing. Thus, instead of writing test classes, we will write test functions like this:

.. code-block:: python
.. code-block:: python

def test_really_cool_feature():
....

class TestReallyCoolFeature(tm.TestCase):
....
Sometimes, it does make sense to bundle test functions together into a single class, either because the test file is testing multiple functions from a single module, and
using test classes allows for better organization. However, instead of inheriting from ``tm.TestCase``, we should just inherit from ``object``:

.. code-block:: python

Going forward we are moving to a more *functional* style, please see below.
class TestReallyCoolFeature(object):
....

Using ``pytest``
~~~~~~~~~~~~~~~~

Here is an example of a self-contained set of tests that illustrate multiple features that we like to use.

Expand All @@ -641,7 +652,7 @@ Here is an example of a self-contained set of tests that illustrate multiple fea
- ``tm.assert_series_equal`` (and its counter part ``tm.assert_frame_equal``), for pandas object comparisons.
- the typical pattern of constructing an ``expected`` and comparing versus the ``result``

We would name this file ``test_cool_feature.py`` and put in an appropriate place in the ``pandas/tests/`` sturcture.
We would name this file ``test_cool_feature.py`` and put in an appropriate place in the ``pandas/tests/`` structure.

.. code-block:: python

Expand Down