Skip to main content
This is a pre-production deployment of Warehouse. Changes made here affect the production instance of PyPI (
Help us improve Python packaging - Donate today!

Describe-style plugin for pytest

Project Description
.. image::

Describe-style plugin for py.test

pytest-describe is a plugin for py.test that allows tests to be written in
arbitrary nested describe-blocks, similar to RSpec (Ruby) and Jasmine

The main inspiration for this was a `video
<>`_ by Gary Bernhardt.


You guessed it::

pip install pytest-describe


.. code-block:: python

def describe_list():

def list():
return []

def describe_append():

def adds_to_end_of_list(list):
assert list == ['foo', 'bar']

def describe_remove():

def list():
return ['foo', 'bar']

def removes_item_from_list(list):
assert list == ['bar']

Why bother?

I've found that quite often my tests have one "dimension" more than my production
code. The production code is organized into packages, modules, classes
(sometimes), and functions. I like to organize my tests in the same way, but
tests also have different *cases* for each function. This tends to end up with
a set of tests for each module (or class), where each test has to name both a
function and a *case*. For instance:

.. code-block:: python

def test_my_function_with_default_arguments():
def test_my_function_with_some_other_arguments():
def test_my_function_throws_exception():
def test_my_function_handles_exception():
def test_some_other_function_returns_true():
def test_some_other_function_returns_false():

It's much nicer to do this:

.. code-block:: python

def describe_my_function():
def with_default_arguments():
def with_some_other_arguments():
def it_throws_exception():
def it_handles_exception():

def describe_some_other_function():
def it_returns_true():
def it_returns_false():

It has the additional advantage that you can have marks and fixtures that apply
locally to each group of test function.

With pytest, it's possible to organize tests in a similar way with classes.
However, I think classes are awkward. I don't think the convention of using
camel-case names for classes fit very well when testing functions in different
cases. In addition, every test function must take a "self" argument that is
never used.

Shared Behaviors

If you've used rspec's shared examples or test class inheritance, then you may
be familiar with the benefit of having the same tests apply to
multiple "subjects" or "suts" (system under test).

.. code-block:: python

from pytest import fixture
from pytest_describe import behaves_like

def a_duck():
def it_quacks(sound):
assert sound == "quack"

def describe_something_that_quacks():
def sound():
return "quack"

# the it_quacks test in this describe will pass

def describe_something_that_barks():
def sound():
return "bark"

# the it_quacks test in this describe will fail (as expected)

Release History

Release History

This version
History Node


History Node


History Node


History Node


History Node


History Node


History Node


History Node


History Node


History Node


Download Files

Download Files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

File Name & Checksum SHA256 Checksum Help Version File Type Upload Date
pytest-describe-0.11.0.tar.gz (6.4 kB) Copy SHA256 Checksum SHA256 Source Oct 7, 2016

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting