Q: One of our teams is looking for ways to not duplicate effort with their Feature files & BDD scenarios. They initially wanted only their repo to be the source of truth but product teams don’t have access to the repo. So i’m wondering how teams are managing their Feature files, where are they storing their source of truth(feature files) and how are they keeping them in sync with their repo? We are using cypress, Jira, Confluence as tools. Any plugins available? What are people doing?
why are you asking this?
An issue i’ve come across before but curious how others are doing this.
what have you tried already?
Jira being source of truth and a plugin/custom code which extracts feature files from Jira and updates the repo. But this easily became slow and sluggish. Benefit, product and other member with no access to the repo can add or update the scenarios.
Other option i was thinking of was to make the repo the source of truth and have a utility or pipeline task which collates the feature files and uploads them to jira/confluence. So updates can be made in the repo and them published somewhere. Issue with this is that Product can’t directly update or add scenarios
I’ve seen a couple of discussions where they avoid Confluence/Jira altogether!
BDD feature files could be in the pipeline while the product can have access to
them. Any change in the examples would automatically trigger the necessary
conditions which are in turn linked to TDD tests and implementation.
Is this something that could work for your scenario?
If the feature files are already in version control I’d want to keep this as the single source of truth. Is there anyway to get people read access to those files? Seems to me that sorting access would avoid lots of other headaches.
The terminal isn’t everyones best friend sadly plus it’s a large team.
Found another option anyway, there’s a package that can generate html/pdf from feature files in the repo. So decided to go down the route of repo being the source and we publish pdf/html copies for reviews
Will share details when we have something implemented using this
pickles doc npm package: picklesdoc - npm
Um, there is the problem. @flynnbops beat me to it I see. It’s quite common for a friction point in any teams process to be a larger blocker than it makes sense. I’ve had to shift from working in a organization attitude where you “only fix your own shit”, to one where things are integrated, and integration is the thing, it is open.
As someone who is, often wrong in my approach of a problem, I think, it’s a great idea to work around this barrier, but ultimately any workaround becomes a resource-distraction or worse. A workaround can become a false abstraction and substitute for actually being part of the solution as an entire organization with one goal and one purpose. Keeping pickled file views in sync across multiple branches will probably blow up on you if teams switch from main-line development to feature branches for example. I would go with making sure everyone is looking at the same single source of truth. That might be actual nightly test reports themselves that can include the BDD files, or it might be getting eyeballs on the files in whatever branches they are in. Which might not be so bad as a branching and process-understanding exercise. Eyeballs are always better than tools.