Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Glob support for fixture file #298

Open
sandra-ouadghiri opened this issue Apr 19, 2021 · 3 comments
Open

[Feature] Glob support for fixture file #298

sandra-ouadghiri opened this issue Apr 19, 2021 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@sandra-ouadghiri
Copy link

sandra-ouadghiri commented Apr 19, 2021

Current behavior:

If you have
fixture (folder) > licences (folder) > valid-licence.json and unvalid-licence.json

This doesn't work

cy.get('[data-cy="file-input"]')
  .attachFile('valid-licence.json');

This doesn't work

cy.get('[data-cy="file-input"]')
  .attachFile('**\valid-licence.json');

(nor any variations around that)
Error message resolves 'ok' on paper, but I guess ** is not interpreted as I hope it would.

Error:    Error: A fixture file could not be found at any of the following paths:
> cypress\fixtures\**\valid_license.json
> cypress\fixtures\**\valid_license.json{{extension}}

This works

cy.get('[data-cy="file-input"]')
  .attachFile('licences\valid-licence.json');

Desired behavior:

I'd like to be able not to specify the folder path precisely.
For example by being allowed to use Glob in path.

I am using Gherkin, and in this context, it is still useful to use folder to organize fixtures, but I'd like my step to remain generic. Having somethign like an extra word in the step to retrieve the folder name, or any other mecanisms feels like adding code that brings no value.

This would be very cool

When  I upload the invalid_license.json file

and

When(/^I upload the (.*?) file$/, (fileName) => {
  cy.get('[data-cy="file-input"]')
      .attachFile(`**/${fileName}`);
})

Versions

"cypress": "^6.5.0",
"cypress-cucumber-preprocessor": "^4.0.0",
"cypress-file-upload": "^5.0.6",

@sandra-ouadghiri sandra-ouadghiri added the enhancement New feature or request label Apr 19, 2021
@abramenal
Copy link
Owner

abramenal commented Apr 30, 2021

Hi @sandra-ouadghiri
Thanks for submitting the issue!

I believe this is something that should be resolved by end user. For example, what I have in mind is:

// Input:
When  I upload the licences/invalid_license.json file

// And then
import path from 'path';
// ...
When(/^I upload the (.*?) file$/, (filePath) => {
  const [fileName, filePath] = filepath.split(path.sep)
  cy.get('[data-cy="file-input"]')
      .attachFile(`**/${fileName}`);
})

Would this work? Or am I missing something?

I feel having a glob implemented would make file upload more error-prone. Imagine situation where I have this folder structure:

/fixtures
  /licences
     test.jpg
  /avatar
     test.jpg

If I would use glob in tests

cy.get('[data-cy="file-input"]')
  .attachFile('**\test.jpg');

which file is supposed to be uploaded?

If it is just first found, then it might be not obvious for the end user. If it should throw, it needs a good extra level of validations, but still too much complexity I feel (comparing to the example I've shown)

@sandra-ouadghiri
Copy link
Author

sandra-ouadghiri commented Apr 30, 2021

Hi,
It's kind of what I do currently.

When(/^I upload the (.*?) (.*?) file$/, (fileName, folderName) => {
  cy.get(getSelector('fileUpload'))
      .attachFile(`${folderName}s/${fileName}`);
})

When I upload the invalid.json license file

/fixtures
  /licences
     invalid.json

But I felt like stating the folder name like that was a bit forced. I try as much as possible to prevent showing the test framework implementation to emerge in gherkin sentences but I guess sometimes it can't be prevented.

I did only consider a case where the dev doesn't name everything the same (else implementing the glob in your step is not a good idea), which may not the right way to think about this indeed! This would need to be handled out of cautious. And if the lib doesn't send back a clear error (like cypress when a selector found multiple elements matching) then it would be a problem 🤔. Which means a more complex development. So yep, you're totally right.

Still think it would be cool (but I'm a user héhé not a maintainer). With an error thrown if mulitple files matches. But I get your point. Whatever you decide for now, thanks for taking the time to respond & for the example. If my folder organisation becomes more complex I'll probably go to your example implementation (with explicite path). Hopefully both our examples will help someone else ;).

@sandra-ouadghiri
Copy link
Author

Are the ** in your first example a typo? I guess it is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants