Reformat cucumber feature files to be more succinct

[al-niessner]

💡 Description

Feature file cleanup

Any given line in the cucumber is a mess. It allows tests to communicate (cross-talk) removing the most important aspect of a unit test - its independence. Should be something like:
| title | dataname | count | expectation | validate_command |

Concrete would be

| NASA-PDS/validate#84 | github71  | | | -C {datadir}/catalog.xml --skip-context -t {datadir}ELE_MON.xml |
| NASA-PDS/validate#71 | github71  | 1 | | -C {datadir}/catalog.xml --skip-context -t {datadir}ELE_MON.xml |
| NASA-PDS/validate#71 | github71  | 2 | error.label.schema=1,warning.label.schema=1 | -C {datadir}/catalog.xml --skip-context -t {datadir}/ELE_MON_2.xml |

Notes:

1. They all use the same data directory as they currently do, but 84 is a standalone test; meaning no variation like 71.
2. The first two expect no errors or warnings otherwise fails.
3. The last one expects 1 error and 1 warning and if gets any other, it fails.

This much shorter line pushes work to StepDefs. It now must use the dataname, the count, and the current resourceDir to generate datadir as well as reportDir. It must create reportDir if it does not exist. It must append -r {reportDir}/report.json -s json to every command.

Doing so should clean up the cross-talk, make the feature file more readable, and close many of the false positives given the way that expectation processing is currently handled.

⚔️ Parent Epic / Related Tickets

No response

[jordanpadams]

@al-niessner definitely agree with this improvement. I tried a similar-ish improvement in pds4-information model, but I like yours better: https://github.com/NASA-PDS/pds4-information-model/blob/main/model-lddtool/src/test/resources/features/validate.feature#L19.

Once we make this updates here, I will create a ticket to do the same over there (or I can just borrow the code).

[jordanpadams]

One minor recommend update:

| testId | title | dataname | count | expectation | validate_command |

testId should be unique (where possible), so it can be the issue number, or where there is >1 we should append a letter like NASA-PDS/pds4-information-model#784a. This is just so they don't collide when we try to insert this information into other databases.

[al-niessner]

I was adding count to testid in StepDefs making the unique id to prevent id from being 1 and count 2.

…

On Tue, Jan 7, 2025, 11:46 Jordan Padams ***@***.***> wrote: One minor recommend update: | testId | title | dataname | count | expectation | validate_command | testId should be unique (where possible), so it can be the issue number, or where there is >1 we should append a letter like NASA-PDS/pds4-information-model#784a. This is just so they don't collide when we try to insert this information into other databases. — Reply to this email directly, view it on GitHub <#1102 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIUBIWRRQ7LAYM5PQZGBG32JQVK5AVCNFSM6AAAAABUWFIDZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZWGA4TSMBRGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[al-niessner]

@jordanpadams @tloubrieu-jpl

You wanted information added to feature files to map tickets to releases or something. It caused the split of pre 3.6 and 3.6.x which I take it is not really valid because we are off to a newer release and not new file. So, if you could embed a single number or word what would it be?

[jordanpadams]

@al-niessner it is really just to make it more usable/readable. In general, we just want to include the tag in the breakup of the file. so @v3.6.x. now would be a separate set of tests @v3.7.x. Filenames work, or we can just include it all in one file if that is preferred.

https://github.com/NASA-PDS/validate/blob/main/src/test/resources/features/3.6.x.feature#L9