Move BDD feature files into NMSampleLocations

[chasetmartin]

@jirhiker @kbighorse @jacob-a-brown @ksmuczynski @jasnakai
I'd like to start a discussion about moving BDD feature files to live in the NMSampleLocations Repo, so they are as close to the business logic as possible. Because:

• Features usually encapsulate domain logic that should live in NMSampleLocations (Ocotillo) - keeping feature files in the API repo aligns ownership with responsibility.
• The API defines behavior; so placing features here ensures backend test coverage is closer to the implementation.
• Keeps domain features versioned with the Ocotillo code, reducing drift between features, tests and implementation.
• Backend pipelines can run feature tests directly without needing to pull or sync the "3rd" BDD repo.
• The UI repo can focus on presentation logic and integration testing.

[jacob-a-brown]

I like your suggestion of moving them into NMSampleLocation (to be renamed OcotilloAPI?) for the reasons you listed. I like that it keeps proximity to the code and implementation. I also like that it'd decrease the number of repos we'd need to maintain.

[jacob-a-brown]

I'm reading about setting up and using fixtures. It seems like those fixtures are defined in tests/features/environment.py, but they are invoked in .feature files. Since the former is in NMSampleLocations but the latter are in OcotilloBDD getting them to work together will be a bit cumbersome. If, however, BDD feature files are moved into NMSampleLocations it'd probably be easier to maintain and use fixtures.

[jirhiker]

when doing local development the feature files need to be copied into NMSampleLocations . This is done automatically by run_bdd.sh. There should be no issue having an environment.py file defined in NMSampleLocations as long as its not overwritten when the feature files are copied

The point of having the feature files live in OcotilloBDD is to make it easier on the Product manager.

[jacob-a-brown]

If someone is developing both the .feature file and behave test locally, using run_bdd.sh will complicate the process due to the git commands. What if, instead of applying OcotilloBDD to frontend/backend repos, .feature files are developed in each repo and then when a commit is pushed to staging the files get written to OcotilloBDD via our CI/CD pipeline?

[jirhiker]

Ideally as an engineer you will not be editing the feature files only testing against them. But we can add a flag to run_bed to not copy the bdd repo so local edits to feature files can be explored

[jacob-a-brown]

If the intension is not for us to edit the feature files, then I think that's a good way to proceed 👍