-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
keeping the docs honest #99
base: main
Are you sure you want to change the base?
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -24,5 +24,5 @@ def before_scenario(context, scenario): | |
context.multi_db = True | ||
|
||
|
||
def django_ready(context): | ||
def django_ready(context, scenario): | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If possible the additional parameter should be optional. Maybe change the documentation instead, or in addition? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a strange situation to be in for sure. Either leave the functionality as is and change the docs, which would be a shame in my opinion. Given that there may be useful information in the scenario where you want to create certain data states across a number of features given a scenario pattern. Whereas if you add this PR as is it'll break existing projects raising Perhaps a new cli flag could do the trick where the default remains. Not sure though, it's up to you all. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe change this to be something like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This will always be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @anthonyalmarza I think @kingbuzzman is correct. Would you mind to just fix the docs that way? |
||
context.django = True |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -28,7 +28,7 @@ commands = | |
{envpython} tests/manage.py behave --tags=~@failing --format=progress | ||
|
||
[testenv:bandit] | ||
deps = bandit | ||
deps = bandit==1.5.1 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please, make this Though the related problem should be fixed. Strange. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can do. I think the linked issue is performance related? It looks like the failing job https://travis-ci.org/behave/behave-django/jobs/551031584 failed to honor the tox configuration here https://github.com/behave/behave-django/blob/master/tox.ini#L66. But that's probably a separate issue to the core issue being raised in this PR. |
||
commands = bandit -r --ini tox.ini | ||
|
||
[testenv:clean] | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks like a bug fix. Could you try to reproduce the bug with a unit test? That would be helpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will that fill in the
scenario
correctly?@jenisys @mixxorz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bittner I'm not sure how I'd unit test this without piggybacking off of the cli tests. I.e. I could mock the
django_hook
function in a test that looks like https://github.com/behave/behave-django/blob/master/tests/unit/test_cli.py#L68-L73. Then assert the mock was called with a context and a scenario instance...However it looks like this is just ridding on the core environment functionality where the runner calls the appropriate hook within a behave model. https://github.com/behave/behave/blob/master/behave/model.py#L968 ... So I'm pretty sure the only arg at this stage of the patch is a Scenario instance.