[TIP] PyBehave ?!?

[Raphael Marvie]

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