How are your teams maintaining their BDD /Feature files in a repo and an external source for other team members to contribute and update? How to avoid duplicate effort?

Archive
,
1

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
4 Likes
2

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?

1 Like
3

Yea would be good to avoid both. How do they access it in the pipeline? Do they get deployed somewhere ?

1 Like
4

I’ll get back to you on that as there seem to be a few ways of doing that. Will respond in this thread. Thanks for your patience.

5

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.

I appreciate organisations do stuff differently.

6

Give access to them :smiley:

7

@flynnbops @joaofarias Yea sadly for us they’ll need to setup ssh keys etc to access our repo hence a difficult option to go down. :grimacing:

8

Why is it difficult? SSH keys setup takes two or three commands…

3 Likes
9

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
JS library:
pickles doc npm package: picklesdoc - npm

http://www.picklesdoc.com/ ? Allows exporting the feature files into html and publish them. eg
HTML copy: Features

Docker container:

10

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.

1 Like
11

Wanted to share the solution

Solution (javascript):
A Script which can be run which pulls all feature files and converts them to a single PDF file or static HTML file which can be shared.

Benefit:
repo can be main source of feature files and pdf or static html can be shared/published for other teams to view

How to implement(macOs):

Add the following to your package.json

  • “node-pandoc”: “^0.3.0”, “pdflatex”: “^0.0.1”, “picklesdoc”: “^1.2.1”,
  • npm install node-pandoc --save-dev
  • npm install pdflatex
  • npm install --global picklesdoc

Copy this file into relevant folder

add the following scripts to your package json
*

  • “generateTex”: “picklesdoc tex ./folder with your feature file/ ./my-document.tex --title=‘Features Report’”,
  • “generatePDF”: “yarn generateTex; echo pdf| node .path to file/featurefile-to-pdf.js”,
3 Likes
12

Glad you found something that works. Hope it works out long term. :muscle:

2 Likes
13

Thanks for popping back on this post and sharing the solution @rforjoe. Great to see. :slightly_smiling_face:

1 Like