[TIP] PyBehave ?!?

Kumar McMillan kumar.mcmillan at gmail.com
Thu Mar 15 08:38:12 PDT 2007


I've been experimenting with Michal's spec plugin [1] and I think you
may be able to achieve what you are after with it.  That is, the
ability to extract a readable specification from a test for
stakeholders.

taking:

Given some initial context,
When an event occurs,
Ensure some outcomes.

to be:

Given a user of the financial group
When logged in
Ensure user can view invoices

then you could write a test like so:

import unittest
class TestUserOfTheFinancialGroup(unittest.TestCase):
    def test_when_logged_in_user_can_view_invoices(self):
        pass

and get from nosetests:

$ nosetests --with-spec

User of the financial group
- when logged in user can view invoices

----------------------------------------------------------------------
Ran 1 test in 0.004s

OK

This doesn't strictly follow a structure of context->event->outcome
but it still illustrates the concept.  Using Fitnesse [2] might be
another way to go.

k


[1] http://darcs.idyll.org/~t/projects/pinocchio/doc/#spec-generate-test-description-from-test-class-method-names
[2] http://agiletesting.blogspot.com/2006/02/running-fitnesse-tests-from-command.html


On 3/15/07, Raphael Marvie <raphael.marvie at lifl.fr> wrote:
>
> Hi,
>
> I do agree on the "philosophical" aspect of BDD that can be achieved
> using existing tool (and in practice approach is more important than
> tools as behavior means testing interactions more than state). I was
> wondering about the two following expressions:
>
> As a [X]
> I want [Y]
> so that [Z]
>
> and
>
> Given some initial context,
> When an event occurs,
> Ensure some outcomes.
>
> in order to easily define scenario / acceptance tests. It is true we can
> achieve this using existing python tools and I find your proposal of
> using "with" interesting. What I had in mind was to make the acceptance
> test as easy to read as possible for a end user and as easy to write as
> a possible for a python developer.
>
> I do not expect to stick to jBehave syntax and structure, I am more
> interested in using <Given, Event, Ensure> as basic artifacts to write
> tests (whatever their final implementation) and to see if it improves
> the writing / reading of tests (improve comparison function has to be
> defined).
>
> Thanks for the comments (same for Kumar).
>
> Cheers,
>
> r.
>
> Michał Kwiatkowski wrote:
> > On 3/12/07, Raphael Marvie <raphael.marvie at lifl.fr> wrote:
> >> Is any one working on a python implementation of jBehave or something
> >> similar to jBehave in a python way? I am thinking of having a look at
> >> it, but want to check first if someone is already on the track.
> >
> > I didn't heard of any Python framework for BDD, but it doesn't mean
> > you can't achieve the same effect with currently existing tools. There
> > is unittest and doctest in standard library, there is
> > python-mock[1]/pyMock[2]/minimock[3] for mocking and stubbing, there
> > is nose[4] for running test, figleaf[5] for code coverage, spec
> > plugin[6] for specifications. What is missing is this small shift in
> > terminology, which IMHO isn't really needed if people already know
> > what TDD is about. But if you insist you could try to come up with
> > some nice syntax for setting contexts and specs. I would use "with"
> > keyword to achieve syntax similar to:
> >
> > with context("Empty queue") as c:
> >    with setup():
> >        c.queue = Queue()
> >    with spec("should be empty"):
> >        assert Queue.isempty() is True
> >
> > Another issue of changing asserts into expectations could be more
> > tricky. Using jBehave-like syntax you would like to change assert
> > above into:
> >
> >    ensure_that(Queue.isempty(), eq(True))
> >
> > IMHO this is not easier to read and may sometimes be even less clear
> > (as people are used to asserts already). RSpec[7] has much nicer
> > syntax, but without open object class in Python this cannot be
> > achieved in any standard way:
> >
> >    Queue.should_be_empty()
> >
> > What I suggest is to build on top of existing tools to prevent
> > reinventing the wheel. If you like jBehave syntax, create a
> > unittest.TestCase derivative so it integrates nicely with whatever
> > people are using now. If you feel your mocking library is missing
> > important features, contribute patches. You may actually end up
> > writing a nice tutorial which describes specific setup for doing BDD
> > without actually creating any new framework. Oh, and remember I only
> > scratched a surface of existing Python testing tools. More
> > comprehensive list is on Cheesecake wiki[8].
> >
> > [1] http://python-mock.sourceforge.net/
> > [2] http://theblobshop.com/pymock/
> > [3] http://blog.ianbicking.org/minimock.html
> > [4] http://somethingaboutorange.com/mrl/projects/nose/
> > [5] http://darcs.idyll.org/~t/projects/figleaf/README.html
> > [6] included in pinocchio package:
> > http://darcs.idyll.org/~t/projects/pinocchio/doc/
> > [7] http://rspec.rubyforge.org/
> > [8] http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy
> >
> > Cheers,
> > mk
>
> --
> Raphael Marvie, PhD                http://www.lifl.fr/~marvie/
> Maître de Conférences / Associate Professor  @  LIFL -- IRCICA
> Directeur du Master Informatique Professionnel spécialité IAGL
> Head of Master's in Software Engineering     +33 3 28 77 85 83
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>


More information about the testing-in-python mailing list