Skip to content

Documentation for Cypress.ensure #5054

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

Merged
merged 9 commits into from
Feb 15, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
80 changes: 80 additions & 0 deletions docs/api/cypress-api/ensure.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
---
title: Cypress.ensure
---

`Cypress.ensure` is a collection of helper methods for making assertions. They
are mostly useful when writing [custom queries](/api/cypress-api/custom-queries)
or [custom commands](/api/cypress-api/custom-commands).

Most functions on `Cypress.ensure` accept a
[`subject`](/guides/core-concepts/introduction-to-cypress#Subject-Management)
argument, check an assertion, and throw an error if the assertion fails. These
functions have no return value.

## Syntax

```javascript
// Type of argument
Cypress.ensure.isType(subject, type, commandName, cy)​
Cypress.ensure.isElement(subject, commandName, cy)​
Cypress.ensure.isWindow(subject, commandName, cy)
Cypress.ensure.isDocument(subject, commandName, cy)​

// State of DOM element
Cypress.ensure.isAttached(subject, commandName, cy)​
Cypress.ensure.isNotDisabled(subject, commandName)​
Cypress.ensure.isNotHiddenByAncestors(subject, commandName)​
Cypress.ensure.isNotReadonly(subject, commandName)​
Cypress.ensure.isScrollable(subject, commandName)​
Cypress.ensure.isStrictlyVisible(subject, commandName)​
Cypress.ensure.isVisible(subject, commandName)​
```

:::caution

Many of these functions accept an optional `onFail` argument. This is a legacy
feature used to customize the thrown error, and may be removed in a future
release; we recommend against relying on it. If you need more control over the
error thrown, write your own `ensure` function instead.

:::

Comment on lines +33 to +41
Copy link
Contributor

Choose a reason for hiding this comment

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

IMO we should just not document this, since the user can just try...catch to get the same functionality as onFail, right? Then we can just rip it out when we're done using it internally.

Suggested change
:::caution
Many of these functions accept an optional `onFail` argument. This is a legacy
feature used to customize the thrown error, and may be removed in a future
release; we recommend against relying on it. If you need more control over the
error thrown, write your own `ensure` function instead.
:::

Copy link
Member

Choose a reason for hiding this comment

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

I gave a similar suggestion to not document this #5048 (comment). The onFail ties in to how this would be removed up if this callback matched the command onFail behavior, so it's require quite a bit of user-knowledge to handle this correctly. I like @flotwig's suggestion for handling with try-catch.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The reason I documented it here is because people's intellisense / TS will show them that there's an additional argument, and they'll see it if they examine the code.

Undocumented arguments are the worst, so I figure a little warning "this exists but don't use it" would be preferable.

Was the response I gave to Emily, and I still feel the same way - if it exists, we should not leave it silently undocumented. I've found myself in this boat several times dealing with other projects, where I see an argument is there, but the documentation is completely silent. What does it do? Why is it there? Your own code uses it, to what purpose?

I think a warning "it exists, but don't use it" is appropriate, as well as not including it in the documented function signatures.

### Usage

**<Icon name="check-circle" color="green" /> Correct Usage**

```javascript
Cypress.Commands.addQuery('getChildById', function (id) {
return (subject) => {
// Verify that the subject is an element, document, or window object
Cypress.ensure.isType(
subject,
['element', 'document', 'window'],
'getChildById',
cy
)

return $$(`#${id}`, subject)
}
})

const queryName = 'verifyElementActionable'

Cypress.Commands.addQuery(queryName, function (...args) {
return (subject) => {
// Verify that the subject fulfills a variety of conditions
Cypress.ensure.isElement(subject, queryName, cy)
Cypress.ensure.isVisible(subject, queryName, cy)
Cypress.ensure.isNotDisabled(subject, queryName, cy)
Cypress.ensure.isNotReadonly(subject, queryName, cy)

return subject
}
})
```

## See also

- ["Custom Queries"](/api/cypress-api/custom-queries) contains more information
about writing custom queries, which is the main use-case for the `ensure`
functions.