@stof @acoulton those are some very good points - I'll see if I can make it work.

@stof on the normalisation:

1. Feature description is tracked at Feature description whitespace does not match Cucumber #209 - I think there is a valid argument for not parsing this the same as cucumber/gherkin: I think it's the only place where the indentation from the original file is preserved, and IMO there's no good reason for that to be the case...
2. keywordType looks like a custom property that we attempt to populate with e.g. Given / When etc for steps like And, based on the steps that have come before. There's no equivalent concept/property in the cucumber/gherkin ndjson hence there is nothing to compare against - CucumberNDJsonAstLoader just populates it the same as the keyword value. I suppose we could implement similar logic to give it a value in CucumberNDJsonLoader, but I'm not sure how useful that is - ignoring it from the comparison is probably just as effective?
3. arguments looks like it's just because CucumberNDJsonAstLoader doesn't attempt to load/parse step arguments. It looks like those are present in the NDJson (as either docString or dataTable keys) so I'm not sure whether there was a problem parsing them originally, or whether it was just felt that it was not required. This would probably be worth fixing, as I agree it'd be useful to compare our parsing of the table and pystring arguments are well.

I think each of these are probably separate things to discuss / address in their own issues / PRs.

In the meantime, I agree that we should either register a custom comparator to the assertEquals or do the normalisation inline in this test. IMO for this PR it would be sufficient to just inline the method bodies of @uuf6429's ->withXX methods into the places he's calling them in the test.

Done, I simply expanded the normalizer method since it sounded more natural than having with/copy methods.

I considered a custom comparator, but:

• comparing with assertObjectEquals() I would need to implement an equality method for all relevant classes - while it could be generally useful, it's too specific to testing.
• adding a custom comparator sounded like a lot of work - new class with a lot of logic, registered in the test bootstrap
• using assertThat() with a custom constraint class also looked too complicated

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.86%. Comparing base (b08b4d4) to head (7cc96d8).
Report is 1 commits behind head on master.

@@             Coverage Diff              @@
##             master     #319      +/-   ##
============================================
+ Coverage     96.70%   96.86%   +0.16%     
+ Complexity      602      600       -2     
============================================
  Files            36       36              
  Lines          1760     1724      -36     
============================================
- Hits           1702     1670      -32     
+ Misses           58       54       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I'm fine with using readonly properties. However, I suggest having a policy banning the usage of readonly classes (even though our support of PHP 8.1 currently forbids it until we bump our min PHP versions).
non-final readonly classes are a maintenance nightmare, because both adding and removing the readonly keyword is a BC break (due to the fact that the whole inheritance tree must be either readonly or non-readonly). Readonly classes are also incompatible with property hooks (while property hooks are a formidable tool to write BC layers when refactoring a class based on public properties rather than getters).
To me readonly classes have much bigger drawbacks than advantages (saving a few keystrokes by avoiding to repeat the readonly keyword on each property is really their only advantage, and IDEs autocomplete the keyword so we don't even save 9 keystrokes per additional properties but less than that).

I'm fine with using readonly properties. However, I suggest having a policy banning the usage of readonly classes

@stof agreed. Are you otherwise happy with this PR?

@carlos-granados that wouldn't have worked - as soon as the properties are made private, tests would fail. The only way is if I did the normalizers first and then made the properties private in a child branch, but it would have ended up messier and somewhat counterintuitive.

On a related note, GitHub makes a mess out of contributed PRs (e.g. showing huge diffs without factoring in other PRs), which slows down reviewing a lot - which is why I'm avoiding dependent PRs, despite being my day-to-day flow.

I'd like to point out that my plan was to fully integrate PHPStan by the end of January - at this point I don't even remember anymore what I was doing that required or warranted setting up PHPStan... and now I just don't want to leave it half-finished.

(to be clear, I appreciate everyone's efforts)