Cypress Component testing specpattern automatic e2e-pattern exclude

[Shaegi]

Current component testing documentation states:
Note that any files found matching the e2e.specPattern value will be automatically excluded. (ref: https://docs.cypress.io/guides/references/configuration#component)

In my case I have a pretty global pattern for my e2e tests since I'm working in a monorepo which has some performance issues with too specific glob patterns. Therefore I wanted to exclude component specPatterns via excludeSpecPattern-config, but it seems like automatic exclusion doesn't respect excludeSpecPattern.

To be more precise my e2e-config is the following:

    specPattern: '**/*.cy.{js,jsx,ts,tsx,feature,features}',
    excludeSpecPattern: [
      '**/node_modules/**',
       '**/components/**'
    ]

my component-config is the following:

specPattern: '**/*.cy.{js,jsx,ts,tsx,feature,features}'
excludeSpecPattern: [
  '**/node_modules/**',
   '**/e2e/**'
]

But in component testing it won't find any tests because of the current behaviour.

glob-Search with **/e2e/**/*.cy.{js,jsx,ts,tsx,feature,features} takes around 12s in my case.
glob-Search with **/*.cy.{js,jsx,ts,tsx,feature,features} takes around 2s in my case.

Is this intended? Do I miss some setting to opt-out of this behaviour?

[lmiller1990]

Hi!

From what I can see this use case is not supported right now. I understand why this would be confusing, especially for existing code bases with lots of E2E tests.

For now, the only idea I've got is appending .component.cy.ts to your CT specs. This convention is popular in some communities, like Angular.

The issue with having CT not exclude E2E specs by default is that the default glob of **/*.cy. would capture CT and E2E specs, which is generally not what most users want.

Any other ideas for how we could solve for your use case?

[lmiller1990]

IMO it would be also more consistent if all component-tests are not shown in e2e.

This seems reasonable. I think this makes sense (I haven't thought about any implications, but I don't see any obvious ones).

An issue makes sense to me. 🙏

[Shaegi]

The only downside I could see is that if you misconfigure both you won't get any tests in both of them. But this should be detectable so cypress could give you a warning?
I opened an issue: #25243

[lmiller1990]

Thanks for the issue. I'll try and get some 👀 on this. I expect this won't be until early 2023.

takes around 12s in my case.

That's really slow! How big is your monorepo (file count)? I'd like to reproduce this. I wonder if we can just look into improving performance of the globbing.

[Shaegi]

Thanks for picking up the issue! The workaround with file-extension works fine, so this issue won't block me, even tho I really like to see this implemented.
The repo itself contains about 4000 Files (.js,.ts,.tsx exluding node_modules). Cypress itself doesn't seem to have much of a problem with handling that amount with my desired specPattern glob but Im using it in a combination with https://www.npmjs.com/package/@badeball/cypress-cucumber-preprocessor which seems to be alot slower than cypress, but it matches with my own little script using the glob-library.

var glob = require('glob')
var fs = require('fs')

var pattern = '**/*.cy.{ts,js,tsx,feature,features}' // 2-3s
var pattern = '**/tests/e2e/**/*.cy.{ts,js,tsx,feature,features}' // 11-13s

var ignorePatterns = ['**/node_modules/**']

console.time('timer')
var result = glob.sync(pattern, {
  ignore: ignorePatterns,
  follow: false,
  nodir: true
})

console.timeEnd('timer')
console.log(`Found ${result.length} Files`)

I don't know if cypress is using something else / caching the results better. So improving the patternmatching itself should be an issue of the preprocessor not cypress but I still find this behaviour inconsistent.

Hope that helps to understand my usecase

[lmiller1990]

We are using fast-glob or globby (forgot which) but that flies through thousands of files in <1s - something odd is definitely going on, not sure if it's a conflict between the two libraries or something else. Maybe we should look into this before attempting to add a new feature in Cypress (which is a lot more work; we need to consider breaking changes, tests, docs, etc... it's a large undertaking).