@marmichalski this looks good to me, and very helpful, thanks.

Are you happy to take a look at that?

Yea, sure. I'll see what I can do

@marmichalski this looks good to me, and very helpful, thanks.

Only question is about the feature coverage - I think it would probably also be worth specifying behaviour when providing directories, and also when specifying specific scenarios e.g. features/feature1.feature:7? I had a quick look and I can't see existing features that cover these so it would be good to make sure we're not breaking anything.

This has been covered, also covered directories filtering.

I'd suggest restructuring from the current "everything in one .feature file" to the newer approach with a fixtures directory that @carlos-granados used in e.g. #1593 - that would make it easier to have more than 2 feature files in nested directories and reduce the verbosity of the setup in the .feature file itself.

I've had a look at what you are proposing here, but all of the scenarios in this file require quite the same setup - we assert that the features were executed only from properly filtered paths I am not sure if it's worth splitting them out to separate feature files? I believe this setup adds more confidence in the filtering too, eg when you provide features/a as path that features/b is not picked up

@marmichalski thanks for this - it looks good to me. The test failures are due to #1635 - we'll get that figured out and then we will be able to see this green.

I'd suggest restructuring from the current "everything in one .feature file" to the newer approach with a fixtures directory...

I've had a look at what you are proposing here, but all of the scenarios in this file require quite the same setup...

I probably wasn't very clear. I was suggesting that instead of the current "Given a file named ..." in the background, you would have those as actual files in a structure like:

tests\Fixtures\PathFilters:
  - features
    - bootstrap
       - FeatureContext.php
    - a
      - feature1.feature
      - feature2.feature
    - b
      - feature1.feature

Then this feature would look more like:

  Background:
    Given I set the working directory to the "PathFilters" fixtures folder
    And I provide the following options for all behat invocations:
      | option      | value  |
      | --no-colors |        |
      | --f         | pretty |

  Scenario: First feature file only
    When  I run behat with the following additional options:
      | option                      | value   |
      | features/a/feature1.feature |         |

This makes it easier to see the actual directory structure of the files in the fixtures directory. It also reduces the noise from the top of the feature and the "when I run behat" steps (things like the FeatureContext implementation, or the -f pretty, all of which are required but not directly relevant to what we're testing here).

If you'd like to have a go at that that would be great, if not I'd be happy with this as-is and we can migrate it to the newer feature / fixtures approach in due course.

@marmichalski thanks for this - it looks good to me. The test failures are due to #1635 - we'll get that figured out and then we will be able to see this green.

I'd suggest restructuring from the current "everything in one .feature file" to the newer approach with a fixtures directory...

I've had a look at what you are proposing here, but all of the scenarios in this file require quite the same setup...

...
I probably wasn't very clear. I was suggesting that instead of the current "Given a file named ..." in the background, you would have those as actual files in a structure like:
This makes it easier to see the actual directory structure of the files in the fixtures directory. It also reduces the noise from the top of the feature and the "when I run behat" steps (things like the FeatureContext implementation, or the -f pretty, all of which are required but not directly relevant to what we're testing here).
If you'd like to have a go at that that would be great, if not I'd be happy with this as-is and we can migrate it to the newer feature / fixtures approach in due course.

Ah sorry! Added fixtures.

The CI failure seems unrelated - the translations are different when you run the tests with latest dependencies 😢