DRY for function names when applying decorators about pytest-bdd HOT 7 CLOSED

We had some discussions, and the conclusion is that we will stick with the more pythonic way of doing things, so we'll not generate any function names automatically to have idiomatic code everywhere, including the tests.
The readability and tracebility are very important when you have big test project (and we have that)
Just for you it might be not visible yet as i suppose you have small test suite.
My suggestion for you is just to try pytest-bdd in real life for some time, then you'll get that there's not much overhead as you might imagine, if you fully understand what dependency injection is and how to benefit out of it with pytest.
In short, the proposed functionality is not going to happen

from pytest-bdd.

I'm not sure what the big project size is. Currently we have hundreds of tests (scenarios) for java applications (cucumber) and around hundred for python (lettuce). And the dynamic discovery works well - traceability and readability was never problem. I was looking for test framework for my another projects because I like py.test exception handling, error messages and assertions.

'pythonic' you say, I think half of py.test is pretty magic anyway, and there is a lot of autogeneration, not saying about paramerize and such stuff, but as you wish :-)
Anyway thanks for feedback.

from pytest-bdd.

py.test has a lot of magic inside, but the user test code is normal
idiomatic python - that's what i mean.
things like:

@when('some action')
def _():
pass

@when('some other action')
def _():
pass

who understands it? why the function name is the same and why it still
works?
and the traceability:

@Scenario('Some scenario')
def _():
pass

where do i see the actual test name? of course i 'learn' that it's a
test_some_scenario because i know the rule, but that's ugly...

about the size of the project: we have like 1k bdd tests

On 8 January 2015 at 23:13, Tomasz Czyż [email protected] wrote:

I'm not sure what the big project size is. Currently we have hundreds of
tests (scenarios) for java applications (cucumber) and around hundred for
python (lettuce). And the dynamic discovery works well - traceability and
readability was never problem. I was looking for test framework for my
another projects because I like py.test exception handling, error messages
and assertions.

'pythonic' you say, I think half of py.test is pretty magic anyway, and
there is a lot of autogeneration, not saying about paramerize and such
stuff, but as you wish :-)
Anyway thanks for feedback.

—
Reply to this email directly or view it on GitHub
#89 (comment)
.

Anatoly Bubenkov

from pytest-bdd.

OK, I know what you mean. I tried to find a why to bypass writing it twice but probably there is no good way in python, hence the konira guys made a DSL with python.

That's pretty good test coverage. If that works for you with that much and you don't consider this code as boilerplate, I think I'll try :-)

from pytest-bdd.

btw: can be helpful for you
http://developer.paylogic.com/articles/how-we-use-pytest-and-pytest-bdd-in-paylogic.html
unveils some aspects of our test suite
we also benefit from the sharing same fixture set both for bdd (functional)
and unit tests and that it can be single test run for all the tests (more
than 4k in total)

On 8 January 2015 at 23:24, Tomasz Czyż [email protected] wrote:

OK, I know what you mean. I tried to find a why to bypass writing it twice
but probably there is no good way in python, hence the konira guys made a
DSL with python.

That's pretty good test coverage. If that works for you with that much and
you don't consider this code as boilerplate, I think I'll try :-)

—
Reply to this email directly or view it on GitHub
#89 (comment)
.

Anatoly Bubenkov

from pytest-bdd.

and btw: with pytest-bdd, because the entry point is not the feature file,
you can have multiple tests for same feature file
In our case we have same single set of feature files, but 2 kinds of tests:
functional and blackbox
functional tests are able to access database directly for the setup (they
use same fixtures as unit tests)
blackbox tests are not allowed to access anything except the browser
but the features are the same!

On 8 January 2015 at 23:24, Tomasz Czyż [email protected] wrote:

OK, I know what you mean. I tried to find a why to bypass writing it twice
but probably there is no good way in python, hence the konira guys made a
DSL with python.

That's pretty good test coverage. If that works for you with that much and
you don't consider this code as boilerplate, I think I'll try :-)

—
Reply to this email directly or view it on GitHub
#89 (comment)
.

Anatoly Bubenkov

from pytest-bdd.

Pretty interesting use case. Thank you for a link.

from pytest-bdd.