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

feat(within): Support cy.within #11

Merged
merged 3 commits into from
Jun 5, 2018

Conversation

npeterkamps
Copy link
Collaborator

What / How:

  • Support cy.within by using cy.state('withinSubject') when available.
  • Support passing in a container within the options object.
  • Since Cypress uses jQuery elements and dom-testing-library expects DOM nodes, created a helper to retrieve the DOM node.
  • Installed wait-port and use it within test:cypress:run to avoid race-conditions.

Why:

See #8

Checklist:

  • Documentation
  • Tests
  • Ready to be merged
  • Added myself to contributors table

…within the options object.

* Installed wait-port and use it within test:cypress:run to avoid race-conditions
Copy link
Member

@kentcdodds kentcdodds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Would be good to get another review though!

Copy link
Collaborator

@sompylasar sompylasar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM overall, but I'd make some adjustments to make things clearer.


it('getByText in container', () => {
cy.get('#nested')
.then((subject) => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear from the documentation https://docs.cypress.io/api/commands/then.html#DOM-element , but as I remember, .then callback gets a jQuery collection in its first argument, not a single DOM element. Could you please verify this?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see, you use Cypress.dom.isJquery(element) to accept both jQuery collection and a single element as the container. This wasn't the case before, so likely requires a documentation update where the container option type is described.

"test:cypress:serve": "serve -l 13370 ./cypress/fixtures/test-app",
"test:cypress:run": "cypress run",
"test:cypress:serve": "serve --listen 13370 ./cypress/fixtures/test-app",
"test:cypress:run": "wait-port --timeout 10000 localhost:13370 && cypress run",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

return element
}

function getContainer(cy, container) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cy is assumed a global in Cypress, too, so either make this function pure and take both Cypress and cy from arguments (and pass Cypress to getElement), or just take both from globals.

@@ -0,0 +1,21 @@
function getElement(element) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

function getFirstElement(jqueryOrElement) { would state the intent clearer.

src/index.js Outdated
@@ -1,4 +1,5 @@
import {queries, waitForElement} from 'dom-testing-library'
import {getContainer} from './support/utils'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder why did you place this file as ./support/utils — the file structure of ./ is not dictated by Cypress, so it's confusing as if the structure mattered for Cypress; just ./utils is enough.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I remembered you already had a utils file within your code from #6:

import {
  makeCypressCommandLog,
  makeElementDebugString,
  getNodeFullText,
} from '../support/utils';

So I just tried to match that 😉

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The snippet I have shown is in the cypress folder of my app where Cypress defines the file structure, it's not in the library code.

* Documented jQuery vs DOM nodes.
* Use Cypress.cy global.
* Renamed function and parameter.
* Moved utils file.
@sompylasar
Copy link
Collaborator

sompylasar commented Jun 4, 2018

@npeterkamps Thanks for the fixes in 6394e7e – I apologize for the confusion that I brought, but I did not notice that command takes cy as its argument, propagated from add-commands:

https://github.com/kentcdodds/cypress-testing-library/blob/7d14b896f6f68775e962d03928a9023f325e0791/src/add-commands.js#L1-L7

I wonder why Cypress is still accessed from the globals, but cy is made injected as a local. Consistency of where to take the references to these objects from is what I try to ensure. Either take both Cypress and cy from globals everywhere, or take both from globals in add-commands (in the one and only place), but otherwise take them as local variables from command arguments and propagate to any utility function that needs them.

@npeterkamps
Copy link
Collaborator Author

Is container currently the only option across all the library APIs where the library takes a DOM element or jQuery collection?

Yes. The only API that cypress-testing-library exposes is the command function that is created for each of the query functions. Looking at the documentation from dom-testing-library, there are two HTMLElement parameters; the one passed to the query functions and the one within the options object for waitForElement. So as far as I'm aware, we're supporting all current options.

I'm questioning this quite broad statement that "cypress-testing-library supports both jQuery elements and DOM nodes." – if we want it to be so, we have to ensure this is true for all the current and future APIs.

Since Cypress uses jQuery elements and dom-testing-library expects DOM nodes, I think it would be quite inconvenient if we don't automatically convert jQuery input to DOM nodes. So I think we do need to ensure that we support both (in the future as well).

@sompylasar
Copy link
Collaborator

Thanks @npeterkamps, all looks good.

@kentcdodds kentcdodds merged commit d105706 into testing-library:master Jun 5, 2018
@kentcdodds
Copy link
Member

Thanks friends!

@kentcdodds
Copy link
Member

🎉 This PR is included in version 2.2.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@sompylasar
Copy link
Collaborator

@kentcdodds I didn't find this in CONTRIBUTING.md, which option should I use just in case I need to merge a PR here (squash and merge? on desktop only? how to compose the message?).

@kentcdodds
Copy link
Member

I think it's in the maintaining.md in the other directory. It's squash and merge and you need to make sure that the commit message is right and you can do that in the GitHub UI

@sompylasar
Copy link
Collaborator

@kentcdodds Found it, thanks!

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

Successfully merging this pull request may close these issues.

3 participants