DRY for function names when applying decorators

[spinus]

Tests are created using @scenario decorator and after that the function has to be written (with unique function name). So basically test name exist in 3 places, feature file, decorator and (kind of) in function name. Instead something like:

@scenario(....)
def _():
    pass

could be used to generate functions automatically searching for unique names.

[bubenkoff]

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

[spinus]

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.

[bubenkoff]

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ż notifications@github.com 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 https://github.com/olegpidsadnyi/pytest-bdd/issues/89#issuecomment-69259517 .

Anatoly Bubenkov

[spinus]

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 :-)

[bubenkoff]

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ż notifications@github.com 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 https://github.com/olegpidsadnyi/pytest-bdd/issues/89#issuecomment-69261167 .

Anatoly Bubenkov

[bubenkoff]

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ż notifications@github.com 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 https://github.com/olegpidsadnyi/pytest-bdd/issues/89#issuecomment-69261167 .

Anatoly Bubenkov

[spinus]

Pretty interesting use case. Thank you for a link.