lettuce vs behave

[noobplusplus]

I was browsing for BDD with Python, and stumbled upon lettuce and behave. 

Behave claims to solve few problems better. Lettuce has a much better eco-system. As of now does not seem to convince me why do I give writing selenium tests directly than writing, features and steps and then call selenium or BeautifulSoup with Modernizer or Request?

The documentation I have found, do not dive deep into django specifc things eg. views, models and forms etc. 

There is a similar stack overflow question, unanswered though.

Please enlighten me!

[Suller Andras]

Hi,

I'm not sure if it helps, but I have a simple Python project (using
Google App Engine) where I used Selenium with Lettuce. Maybe it can be
useful for you:
https://patch-tag.com/r/sullerandras/simple-blog-engine-google-appengine/home

Cheers,
Andras

[Steve Schwarz]

On Wed, Sep 19, 2012 at 9:46 AM, noobplusplus <pure.vin...@gmail.com> wrote:

I was browsing for BDD with Python, and stumbled upon lettuce and behave. 

Behave claims to solve few problems better. Lettuce has a much better eco-system. As of now does not seem to convince me why do I give writing selenium tests directly than writing, features and steps and then call selenium or BeautifulSoup with Modernizer or Request?

IMHO, one reason to use BDD using tools like Lettuce is to facilitate the communication with non-technical members of the team. So using a DSL w/in features/steps keeps the "code lingo" out of the communication. They become testable documents; with the down side of agreeing on the DSL and the mapping of the DSL to the system under test.

Recently I've gone the other way. Write unittests with good names and run them under nose with --spec and show the stakeholders the output of the unittests. To me it is all about the communication and less about the tools. My thinking is use the tools you are most comfortable with.

Best Regards,
Steve
http://tech.agilitynerd.com/

[jenisys]

Steve's answer is right (IMHO).

BDD test frameworks, like Cucumber, Lettuce/Behave, JBehave, SpecFlow, etc., provide a separate textual test description,

which can be executed with a thin test automation layer (which interacts with your system/software under test).

This textual description is often easy to grasp even for non-technical people and provides an (up-to-date) documentation of the system behavior.

Therefore, it often serves as documentation with examples that describes how the system/software behaves.

In general, these tests are also more abstract (=> as acceptance tests) and provide a more high-level view on your software/system.

Sometimes you can add tests without need to extend the test automation layer.

If this aspect (separation between textual test and test automation) is not important you (and you are more productive), you can also use your current test framework.

Note that there are by now also BDD tools that provide a middle way: 

You program like in a normal test framework, and the output is readable text (Given/When/Then or other styles).