@kieran-ryan sorry to bother you again but my questions kinda remain unanswered.
I'm also sorry I didn't create this issue in the right place, as you had suggested.

• From what I managed to understand, the step definitions syntax that utilizes pytest_bdd.parsers is not recognized, right?

• Any thoughts on the issue of importing step-definitions from a library? It should work out of the box?

Thank you for your time.

No worries @neskk

From what I managed to understand, the step definitions syntax that utilizes pytest_bdd.parsers is not recognized, right?

Correct. As such have listed this issue as an 'enhancement' - will need to assess effort to support and get back to you

Any thoughts on the issue of importing step-definitions from a library? It should work out of the box?

Assuming you are referring to including step definitions stored in an external library into your repository either via a submodule or a package (such as through 'pip'). If so, it should be possible by configuring the Cucumber extension or language server to point to where those step definitions are stored in order to scan them e.g. referencing inside a virtual environment could look like "venv/lib/**/shared_steps/**/*.py"

@neskk, interesting to observe some of the design choices with pytest-bdd - I see some slight deviations with multi-lines steps compared to the gherkin parser.

With pytest-bdd:

Given a stub exists with:
  one
  two
When creating a stub with:
  | sample |

With the gherkin parser:

Given a stub exists with:
  """
  one
  two
  """
When creating a stub with:
  | sample |

With Behave, we would include only the first portion of the expression; and would access the table via the context.

@given("a stub exists with:")
def step_impl(context):
    for row in context.table:
        model.add_user(name=row['name'], department=row['department'])

This creates a challenge to handle it appropriately with pytest-bdd, as the table is included in the match itself. To support, will likely need to find a pattern that ignores the additional lines to match only the step portion.

Thinking about what would need to be matched:

1. Is os.linestep required in your case or could \n be used instead? We scan rather than evaluate the code that's referenced. However we could ignore that portion of the expression.

2. Can positional arguments be used with pytest-bdd instead of keyword arguments i.e. if we removed stub_str from the expression - but kept it within the function - would it still run? The reason I ask, we typically handle named parameters as a reference to a Cucumber Expressions Parameter Type - which I assume are unsupported with pytest-bdd; so it may lookup and fail; though leaving it empty will match anything. May not be important if we ignore this section for multiline steps; and we have to consider what's optimal to support pytest-bdd. The following for example would work with behave

   @given("an unnamed parameter {}")
   def step_impl(context, parameter):
       ...

@kieran-ryan hello again, I'm sorry I haven't replied sooner.

To answer your questions:

1. os.linesep is not absolutely required, I think \n would work fine here.
2. Regarding positional arguments, I don't think they are supported on pytest-bdd step-def parser implementation (see https://pytest-bdd.readthedocs.io/en/stable/#step-arguments).
   I ran a test similar to your example:

@given("an unnamed parameter {}")
def step_impl(context, parameter):
    ...

It fails because it tries to look for a fixture named parameter since the parameter was unnamed.

I saw you created a PR for adding support to "parse" syntax. I can try to help test it, but I'm not a much of a TypeScript coder.

Awesome @neskk 💪

Would definitely welcome any contributions if you want to open a PR to the branch of the existing PR? A good place to start would be to get the unit tests running locally (a note you may need node v18) and to replace step definitions with their pytest-bdd equivalent and see what works or breaks. Believe had something working but can’t fully recall status
https://github.com/cucumber/language-service/blob/main/test/language/testdata/python/StepDefinitions.py

A note that the expression builder Test that reads that test data expects a specific set of step definition patterns, but you can extend that similar to what has been done with the JavaScript implementation. If you run into any issues I would be happy to help you contribute, feel free to open a draft PR early if something you want to look at and will help

Thank you for the feedback.
I was referring the PR that you open, I can checkout and try to execute the unit tests.
Right now I can't spare much time to help develop this, especially because I'm not familiarized with the project. I just thought it would be great that the vs-code cucumber plugin actually supported our pytest-bdd step-defs, similarly to how PyCharm makes everything work.

@kieran-ryan

Would definitely welcome any contributions if you want to open a PR to the branch of the existing PR? A good place to start would be to get the unit tests running locally (a note you may need node v18) and to replace step definitions with their pytest-bdd equivalent and see what works or breaks. Believe had something working but can’t fully recall status https://github.com/cucumber/language-service/blob/main/test/language/testdata/python/StepDefinitions.py

NOTES:

• The StepDefinitions.py may be sufficient for testing the language-server
• BUT: They are invalid if you want to use them with behave for example.
  In behave you need to specify which step-matcher is used by using use_step_matcher() (like: parse, cucumber_expressions, re, etc.) before you use it for a step-decorator. Otherwise, the step-registration and later use of these steps will not work.
• pytest-bdd should have a similar problem because it wraps the step-syntax w/ a parser call.
• AND: Python has the naming convention to use snake_case instead of CamelCase for Python modules/packages. Therefore, StepDefinitions.py should be renamed to step_definitions.py.

SEE:

• PEP-008 (naming conventions): https://peps.python.org/pep-0008/
• https://peps.python.org/pep-0008/#package-and-module-names

@kieran-ryan I posted some questions on language-service PR#206. If you can please take a look at it.
I don't know how the guys from Jetbrains managed to support all the pytest-bdd formats, but we should be able to do it too.