-
Notifications
You must be signed in to change notification settings - Fork 10
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
Enhancement: add pytest-bdd parser support #29
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.
I didn't dive into too much because I trust that you can figure out the pytest-bdd specific stuff. Overall, I see lots of duplication, so I wonder if this can pivot a bit. I think we could make our own classes for Feature, Scenario, etc that have all the information we need, and then pass those sanitized objects into our writing to rst logic. Maybe you were thinking that anyway. In other words, use whatever parser to parse the file, then use that parsed file to create the objects we need. So for example, our Feature
object would have an optional examples
value. Behave would never set that, but pytest-bdd might. Then "get info we need" and "turn that info into rst and write it" can be two clearly separate tasks.
I have the same reaction as Ryan. |
I’m glad to hear two votes for moving into some cleaner class-based structure. That’s more or less where it felt like this needed to go, once I got to this point. Just wanted to hear that independently confirmed before I put in the work for the next round. |
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.
Misc quickly reviewed comments.
pyproject.toml
Outdated
@@ -15,6 +15,7 @@ Sphinx = ">=1.3" | |||
sphinx_rtd_theme = ">=0.3.1" | |||
behave = ">=1.2.6" | |||
recommonmark = ">=0.4.0" | |||
pytest-bdd = {git = "https://github.com/rbcasperson/pytest-bdd.git", rev = "scenario-descriptions", optional = true} |
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.
Huh, I hope this reference to a personal repo is something that will evolve into a JGT repo at some point?
(tiny github PR review UI syndrome might be at work here too)
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 am still concerned about this 'personal repo' being used here...
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.
So I've looked a bit into this. poetry
does support most of the more advanced ways you can specify a package, but doesn't appear to properly handle parsing/passing a PR refspec down to pip
/git
. Our options, as best I can determine, are:
- sit on this addition until Ryan's PR merges (it's been awaiting review since Dec 3)
- rework the pytest-bdd parser class to strip out scenario descriptions for now and just add support for scenario descriptions back later when the PR merges
- run with the personal branch from which the PR is sourced until that PR merges (then come back and return our ref to the "official"
pytest-bdd
source)
Working on a team that could benefit today from the full range of what this work currently offers, I'm obviously biased toward option (3) there.
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.
Isn't there maybe a 4th option?
What about using the stock pytest-bdd parser as is, in which case the extra functionality won't come out of the stock parser, but then anyone who wanted to layer in Ryan's PR after the install would get it and the sphinx-gherkindoc part would be ready?
(Sorry, this is a dash-off quick half-baked thought as I didn't have any more time today at lunch)
sphinx_gherkindoc/cli.py
Outdated
if args.pytest_parser: | ||
from .pytest_bdd_writer import feature_to_rst | ||
else: | ||
from .behave_writer import feature_to_rst # type: ignore |
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.
Sadly from a historical perspective, behave is the default if nothing else is specified. Much as I would like to require the parser (well, the syntax, technically) to be actively declared in all cases, that would break existing clients.
Unless we go to a full-on major version number change. :-)
output_file.blank_line() | ||
examples(scenario, feature) | ||
|
||
return output_file |
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.
Ugh, I can't tell just how duplicated this is using the GIthub PR review UI alone.
I'll have to pull the PR and do some diffing and what not.
(So perhaps not tonight unfortunately, hopefully tomorrow)
tests/conftest.py
Outdated
basic_feature = tmp_path / "basic.feature" | ||
test_dir = pathlib.Path(__file__).parent | ||
with open(test_dir / "basic.feature") as feature_fo: | ||
basic_feature.write_text(feature_fo.read()) |
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.
Not sure if that is the same as, or subtly different from, https://docs.python.org/3/library/shutil.html#shutil.copyfile
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.
Question about shutil.copyfile
still stands...
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.
both of these were lift-and-shift, so I didn't look carefully, and missed the comment(s) in the larger rewrite, but I just tested and. shutil.copyfile
works fine here (and below), so I'll make that change.
tests/conftest.py
Outdated
tags_feature = tmp_path / "tags.feature" | ||
test_dir = pathlib.Path(__file__).parent | ||
with open(test_dir / "tags.feature") as feature_fo: | ||
tags_feature.write_text(feature_fo.read()) |
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.
ditto comment re: https://docs.python.org/3/library/shutil.html#shutil.copyfile here too?
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.
ditto here too.
# and tag lines for all the same "words" | ||
|
||
# First, compare non-tag lines | ||
actual_without_tags = [x for x in actual if tag_text not in x] |
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.
Too bad we're not using more_itertools :-)
https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.partition
(Edited to add this is with python 3.7.6)
spun up a new venv and when running envsetup:
|
Upgraded poetry to 1.0.3 and the previous error went away.
|
Pulled and ran against SNBN repo. |
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.
Back to Brad with a few hopefully minor things.
Overall the code looks good.
I have to self-disclaim that the pytest-bdd
specific parts are beyond my familiarity, so I leave it to ye lovers of pytest
to review that with a keener eye.
So I had a few minutes at lunch today, and I tried an experiment.
To semi simulate a potential user environment:
So it seems, and I am not sure if my experiment is fully valid, that this PR could have two sad consequences, depending on how a user's environment is configured:
So while one might argue that option 2 is OK, that really only applies if there are no other PRs merged and no other pytest-bdd releases done before Ryan's is. And, more importantly, all of this working on not depends on the order that a user installs their packages, which is very fragile and would be downright mysterious to anyone who just wants to get some stuff documented. I think if Ryan's PR had a version dink in it, that might help some, but even then, if pytest-bdd does a new release without that PR, we're back again to having to have a very specific ordering of installation for things to work right. That leaves me thinking that the best way to move forward with this PR is not to have the the pytest-bdd option install Ryan's PR and be operable without it, but if someone does come along and add in Ryan's PR after the fact, this code will be able to leverage that without requiring any install/uninstall of sphinx-gherkindoc. |
Tweak test cases such that the pytest scenarios pass with the latest pytest-bdd release, without dropping any coverage around the behave tests.
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.
Took a peep at the latest changes in toto and it seems good.
Want to test against real repo doc build before signing off, that'll be tomorrow morning I hope.
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.
Cannot say I went very deep in to the pytest-bdd part of things not having a real world use case for it.
However, I did just run master and this PR on my real world behave test case and everything built exactly the same except for the usual diff in the environment.pickle file.
tl;dr LGTM!
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.
Looks good to me. Utilize all the engines!
I think this one is "most of the way" there, though it did reveal some of the weaknesses of having left behind the class structure for file parsing -- it makes it much less clear what needs to differ between
behave
- andpytest-bdd
-parsed files, and adds some (potentially unnecessary) complexity to the work of keeping the two in-sync.Consider this a "spike verging on mergeability", but if it leads to larger discussions/changes, I'm ok with that as well.