TypeError: container.querySelectorAll is not a function

[fredbliss]

• cypress-testing-library version: 5.1.1
• node version: 12.4.0
• npm (or yarn) version: 1.21.1 (yarn)

Relevant code or config

describe('anonymous calculator', () => {
  it('can make calculations', () => {
    cy.visit('/')
      .findByText(/^1$/)
      .click()
      .findByText(/^\+$/)
      .click()
      .findByText(/^2$/)
      .click()
      .findByText(/^=$/)
      .click()
      .findByTestId('total')
      .should('have.text', '3')
  })
})

What you did: Attempted to run tjs/cypress-04 branch of https://github.com/kentcdodds/jest-cypress-react-babel-webpack/tree/tjs/cypress-04

What happened:

Reproduction repository:
https://github.com/kentcdodds/jest-cypress-react-babel-webpack/tree/tjs/cypress-04

Problem description:

TypeError: container.querySelectorAll is not a function

Suggested solution:

--

[kentcdodds]

I think this is the same issue that was brought up here: #100 (comment)

Thank you for opening it so we can discuss this. cc @tlrobinson and @twgraham.

When I merged that other PR I didn't realize it was going to break this use case. I personally like this style quite a bit and would like it very much if we could get the benefits that #100 was going for without losing the ability to write tests in this way.

If we cannot, then I think we should revert #100. Anyone have ideas?

[kentcdodds]

I'd also love feedback from @NicholasBoll on this as well.

[fredbliss]

Thanks for the quick response on this @kentcdodds!

[kentcdodds]

Just to be clear, the justification for the style I prefer is based on how get works:

describe('anonymous calculator', () => {
  it('can make calculations', () => {
    cy.visit('/')
      .get('.one')
      .click()
      .get('.plus')
      .click()
      .get('.two')
      .click()
      .get('.equals')
      .click()
      .get('.total')
      .should('have.text', '3')
  })
})

I really like that style and want to make sure we preserve that style for our queries. I think that is least surprising for people.

[tlrobinson]

However, this isn't how contains, find and most other cypress commands work, which I'd argue are more similar to the testing-library commands. get is kind of a special case.

The way Cypress recommends "reseting" to the root element is with end() (but "you can always start a new chain of commands off of cy" is the more common way of doing it anyway): https://docs.cypress.io/api/commands/end.html#Examples

IMHO the ability to chain commands is more important than supporting the above style, which isn't really idiomatic Cypress. IMHO this is much more readable:

    cy.visit('/')
    cy.get('.one').click()
    cy.get('.plus').click()
    cy.get('.two').click()
    cy.get('.equals').click()
    cy.get('.total').should('have.text', '3')

[twgraham]

@kentcdodds I think the comment i made in #100 would only apply to 5.1.0, this is 5.0.2 so it could be a different issue? 🤷‍♂️

[kentcdodds]

Oh, that's true. Maybe it is a different issue. Anyone want to dig in and figure out where the problem lies?

[twgraham]

Scratch that... It could be resolving the next minor version (5.1.0) because the package.json requires ^5.0.2. Probably the same issue 😅

[fredbliss]

Oh, Crumbs. No, I was on 5.1.1, I'm sorry @kentcdodds @twgraham!

[twgraham]

When I merged that other PR I didn't realize it was going to break this use case. I personally like this style quite a bit and would like it very much if we could get the benefits that #100 was going for without losing the ability to write tests in this way.

Your call - I can see the benefits of sticking to the old way, and the new way which @tlrobinson has provided. I don't think you can have it both ways though (from a usability perspective). It would become confusing (magic?) how the command resolves elements. I would also suggest that adding it as an option is a bad idea e.g. findByText(..., { usePrevious: true })

Pick a method and stick with it 👍

[kentcdodds]

Ok, I think that in order to address the breaking change I'm going to revert #100 right now, and then we can talk about the merits of making a breaking change to support it in a new major version bump.