Does a feature have to be a file in the filesystem?

[EinmalMitScharf]

Hi,

is it possible to read a single feature file from a Webservice instead of reading it from file system?

We are going to introduce xRay which supports Cucumber Features. As far as i understand it, i would have to export the feature files from there into a real file and then run the tests.

Question is : Is it possible to skip the save to file part and configure reading feature files via webrequest or maybe read it in some kind of before hook?

xRay Docu :
https://docs.getxray.app/display/XRAY31/Testing+with+Cucumber

Thanks in adance.

[mpkorstanje]

In theory, yes!

Cucumber uses the Java FileSystem API to load feature files (effectively Paths.get(uri)). So you if you provide the path to your feature as x-ray:path/to/features and provide an implementation of FileSystem that handles the x-ray scheme and resolves one or more files from the server, it should be possible.

I've never tried this in practice though.

[EinmalMitScharf]

Thank you :)

I guess we will take a closer look into that. It sounds like implementing some kind of preprocessor which downloads the file and starts cucumber with that is less effort and maybe easier to maintain in the future.

[mpkorstanje]

Yeah. A Maven plugin that operates in the generate-test-resources phases sounds much more sensible. 😄

[nathanchilton]

Hi,

is it possible to read a single feature file from a Webservice instead of reading it from file system?

We are going to introduce xRay which supports Cucumber Features. As far as i understand it, i would have to export the feature files from there into a real file and then run the tests.

Question is : Is it possible to skip the save to file part and configure reading feature files via webrequest or maybe read it in some kind of before hook?

xRay Docu : https://docs.getxray.app/display/XRAY31/Testing+with+Cucumber

Thanks in adance.

Given the contents of the Feature can be streamed from Xray
When you want to execute your test
Then you will still need to write code to implement your step definitions
And your code should be in some sort of version control
But having step definitions stored without the steps could be problematic 
And I wouldn't recommend it

It is important to have a "source of truth". What I have done before (with both qTest and Zephyr Scale), is to make the git repository be the source of truth, holding both the .feature files and the corresponding step definitions, and then writing a script to make use of the test management tool's API to keep the two in sync. The script would compare the version in the test management system to the version in our test repository, and update the test management system's version to match.

This enabled us to develop test plans in Jira, while keeping the .feature files and their step definitions together in git. When it was time to execute the tests, we would provide an id to the test runner, and the after scenario hook would make use of the API to record the result of running the test, so anyone with access to Jira could see the progress of the test execution.

For Xray, this would correspond to what they describe in their documentation as a Pure VCS based workflow.

[EinmalMitScharf]

Thank you for the input.
Problem is that management defined xRay as single source of truth already. We use Cucumber (with different frameworks) already a lot but without xRay. To be honest from an automation point of view we do not need xRay and it causes just more effort.
From my point of view your workflow seems to be a good solution an if i had to decide it i would go with it. Maybe me and my team can discuss it with management.

[nathanchilton]

I wonder if your management has had previous success with using xRay (or something similar) as the single source of truth. I am skeptical, but it's possible that there are good reasons for that approach, which have been proven in practice.

If you and your team have the opportunity to discuss it with your management, hopefully they can help you understand the "why" behind that decision. Perhaps, there are good reasons for it and understanding those can make it easier to support the decision. If there isn't a good reason for why xRay was chosen to be the source of truth, then maybe there is opportunity to rethink that before you go too far down that path.

Good luck!