Thoughts about RSpec for Python

blocks.py

# codec: blocks

describe('articles.views.ArticleView'):

    context('when user has permissions'):

        it('should add new article'):
            # some code

        it('should delete existing article'):
            # some code

    context('when user has no permissions'):
        it('should not add new article')
        it('should not even show article form')

tests.py

from bdd import describe, context, it


with describe('articles.views.ArticleView'):

    with context('when user has permissions'):

        @it('should add new article')
        def test():
            # some code

        @it('should delete existing article')
        def test():
            # some code

    with context('when user has no permissions'):
        # pending tests
        it('should not add new article')
        it('should not even show article form')

How about creating a DSL with its own parser that generates and runs python code. Most python syntax highlight and auto-completion tools can work fine with it (bonus).

For example:

import spec_helper

describe articles.views.ArticleView
    context 'a user with permissions':
        it 'should add a new article':
            # some code
        it 'should delete an existing article':
            # some code
    context 'a user without permissions':
        it 'should not add a new article'
        it 'should not show the article form'

Then RSpec matchers can usually be translated into unittest2 assertions.
http://rubydoc.info/gems/rspec-expectations/RSpec/Matchers

Python unittest2 assertions are not really much more verbose than the .should and .should_not rspec helpers, but more pythonic:

assert expected is False
assert expected is None
assert expected is not None
assert isinstance(expected, list)
assert almost_equal(expected, 55)

As I don't like all those parenthesis (), signs like @, keywords like with and def in the original gist. And RSpec just can't be written as native Python, so no reason to force it - there are other ways.

What about simply using sure ?

https://github.com/gabrielfalcao/sure

What do you all think 2 years later, any suggestions? Still using sure? I am coming from Rspec and Jasmine and not saying I need everything the same, but I like being able to use contexts

I too would be interested in lostmarinero's question.

Im just starting python and come form ruby so rspec Ill let you know what I think and end up using but i like sure

sheesh people. Years later and nothing?

Check out mamba https://github.com/nestorsalceda/mamba

We ended up not using it, but now I wish we had.

@gabrielfalcao sure surely looks like a nice assertion library, thanks for that! :)

However, the discussion here is about a library that helps to structure tests, like RSpec does.
Namely, something that helps you to write test names and their structure, even before you actually write any assertion.
This is a powerful communication and designing tool, that gives you a lot more than simply a cool way to do assertions: it helps you to think, to plan and to adapt later on.
Assertions are probably not that important when it comes to high-level design, except when deciding to use mocks vs stubs.

This excerpt from the RSpec book might be a good introduction to these ideas: http://media.pragprog.com/titles/achbd/outside-in.pdf

I haven't find a really good tool in Python ecossystem for that yet.

mamba looks promising.
There are some other alternatives behave, pytest-bdd, lettuce and etc, but none seems to attempt to help the upfront thinking when design -- they always get in the way, requiring you to write boilerplate stuff.