-
Notifications
You must be signed in to change notification settings - Fork 47
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
Adds the ability to use --behave-runner in the behave command #100
Conversation
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.
This is a rather large PR.
Can you please provide an initial description, which provides the motivation for all your changes and/or a reference to an open issue (in this repository)?
Specifically, I have a hard time to see why you prefer to replace a short command line option by a rather lengthy, hard to memorize one.
@bittner I drastically reduced the changes, turns out i was wrong with my original approach since the TestCase is not used to run the tests, I discovered this when i finally implemented the code. Let me know if you want any additional changes. |
@bittner friendly reminder, would love some feedback. |
@bittner ? |
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.
Hmm, not bad! I love how much you reduced the code needed for this contribution!
Looks like there is some more potential to reduce the code. Go for it! 💯
@bittner Made changes, let me know. |
@bittner ? |
Sorry about that. Taking a look now. |
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.
Sorry, still not all good yet. 😟
behave_django/environment.py
Outdated
|
||
from behave import __main__ as main |
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.
I think you want to import main
like in the management command:
from behave.__main__ import main as behave_main
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.
Cant do this, need to be able to override the function inside behave.__main__
called run_behave
@@ -1,7 +1,9 @@ | |||
from copy import copy | |||
from functools import partial |
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.
Can you explain why it's important to use partial
? What's your motivation for this?
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.
behave_main.run_behave()
takes an optional parameter called runner_class
, if this is not specified, it defaults to behave.runner.Runner
further down the code.
With partial
all im doing is keeping the same callable with no arguments as before but setting the "default" value of runner_class
to what ever class may be inside behave_runner
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.
Just a few more things to change until we reach the finish line. Congratulations! 👍
Would you mind squashing all the commits into one, two or three commits only? Whatever makes sense to put in single commits together. That would be great. The version bump, probably, as a separate commit at the end.
@@ -257,6 +257,14 @@ each scenario instead of flushing the entire database. Tests run much quicker, | |||
however HTTP server is not started and therefore web browser automation is | |||
not available. | |||
|
|||
``--runner`` | |||
******************* |
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.
Please make the *****
only as long as the section title.
``--runner`` | ||
******************* | ||
|
||
Allows to override the test runner class that Behave uses by default. e.g., |
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.
The "e.g.," is lost at the end of this line here. Why not remove it here and use it properly in the next sentence?
******************* | ||
|
||
Allows to override the test runner class that Behave uses by default. e.g., | ||
this will allow you to customize where your feature files are located. |
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.
I'd suggest:
This will allow you, e.g., to customize ...
parser.add_argument( | ||
'--runner', action='store', dest='runner_class', | ||
default='behave.runner.Runner', type=valid_python_module, | ||
help='Tells Behave to use a specific runner. (default: %(default)s)', |
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.
This is actually the Behave runner, not any of those we provide in this project. I'm fascinated!
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.
While I start liking this PR more and more I now start worrying that wondering whether 😏 this feature should actually go into Behave. What do you think about that? 🤔
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.
I'm looking forward to your feedback here. The behave command actually has no -r --runner
option, currently. Maybe it would be desirable to have that possibility also for plain Behave, not only tied to using it with Django, hmm?
I would still merge your efforts here, probably, but:
- name the option appropriately
--behave-runner
(as you had it before) and - open a new issue to discuss migrating the feature to the Behave code base.
I hope that makes sense.
@@ -5,4 +5,4 @@ | |||
__email__ = 'mixxorz@gmail.com' | |||
__url__ = 'https://github.com/behave/behave-django' | |||
__license__ = 'MIT' | |||
__version__ = '1.3.0' | |||
__version__ = '1.3.1' |
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's more than just a bug fix or something. Let's make it 1.4.0
, what do you think?
@bittner I think this makes all the sense in the world, if i move this code over to https://github.com/behave/behave, then there is no need for this PR |
I tested the code in master with the modification ive done to https://github.com/behave/behave-django and it looks good. Closing this PR. Code has been moved to behave/behave#795 |
Let me try to get hold of @jenisys a last time. This should be possible. He has merged things before. |
I'm making a rather large test migration from Aloe to Behave.
Currently, all our tests are inside our apps like so: (py + feature files all in the same folder inside EACH app)
I do not want to make this migration any more painful than it needs to be, so my plan is to modify
behave.runner.Runner
to find my tests in the appropriate place. Right now there is no way for me to modify the way this works.BehaviorDrivenTestRunner
This is the exact reason django exposes--testrunner
and i was very surprised this was something overlooked in this project.Making this modification works great:
./manage.py behave --behave-runner myproject.runner.Runner