Forem: Evgeny Orekhov

More Cypress Best Practices

Evgeny Orekhov — Sun, 02 Apr 2023 14:24:55 +0000

These are some additional Cypress best practices that I haven't seen in any other articles about Cypress.

Use eslint-plugin-cypress

The best way to avoid anti-patterns is to have a tool that will catch them for you as early as possible.

Make sure to enable all available rules:

{
  "extends": [
    "plugin:cypress/recommended"
  ],
  "rules": {
    "cypress/no-force": "error",
    "cypress/assertion-before-screenshot": "error",
    "cypress/require-data-selectors": "error",
    "cypress/no-pause": "error",
  }
}

And make sure to read about each rule to improve your understanding of Cypress.

Use UI assertions to reduce test flakiness

If you find that a certain action sometimes gets performed earlier than it should, then add a UI assertion before it.

In this example we want to wait for a comment to appear before adding another one, otherwise, we may end up with a flaky race condition:

  cy.findByRole("textbox", { name: "Comment" }).type("My first comment");
  cy.findByRole("button", { name: "Post comment" }).click();
+ cy.findByText("My first comment").to("be.visible");
  cy.findByRole("textbox", { name: "Comment" }).type("My second comment");
  cy.findByRole("button", { name: "Post comment" }).click();

Use UI assertions to reduce screenshot flakiness

This is what cypress/assertion-before-screenshot rule is about. If you take screenshots without assertions then you may get different screenshots depending on timing.

Unfortunately, the rule works only with the default cy.screenshot() command, so you need to be diligent if you use a different one, like cy.percySnapshot().

In this example, after publishing a new post, we want to wait for it to appear in the UI before taking a screenshot:

  cy.findByRole("button", { name: "Publish" }).click();
+ cy.findByRole("heading", { name: "My new post" }).to("be.visible");
  cy.percySnapshot("Posts - new post");

Use functions to create reusable commands

In most cases, performing a single meaningful action will involve executing multiple commands and assertions. If you find yourself repeating the same commands over and over, create a function that abstracts them away.

export function goToPosts() {
  cy.findByAltText("Menu").trigger("mouseover");
  cy.findByRole("link", { name: "Posts" }).click();
}

export function createPost(name: string, content: string) {
  cy.findByRole("textbox", { name: "Post name" }).type(name);
  cy.findByRole("textbox", { name: "Post content" }).type(content);
  cy.findByRole("button", { name: "Publish" }).click();
  cy.findByRole("heading", { name }).to("be.visible");
}

export function addComment(comment: string) {
  cy.findByRole("textbox", { name: "Comment" }).type(comment);
  cy.findByRole("button", { name: "Post comment" }).click();
  cy.findByText(comment).to("be.visible");
}

export function deletePost(postName: string) {
  cy.findByRole("button", { name: `Open ${postName} menu` }).click();
  cy.findByRole("button", { name: `Delete ${postName}` }).click();
  cy.findByRole("button", { name: "Yes" }).click();
}

It will make your tests concise and clean:

describe("Posts", () => {
  it("can create a new post", () => {
    const postName = "My new post";

    goToPosts();

    createPost(postName, "My post content");

    addComment("My first comment");
    addComment("My second comment");

    cy.findByText("My second comment").to("be.visible");
    cy.screenshot();

    deletePost(postName);
  });
});

Make production code more accessible

If you find that it's impossible or hard to use an accessible Testing Library query, go ahead and change the production code to make it more accessible. It will make your users happier, and your tests less dependent on implementation details.

- <div onClick={handleClick}>
+ <button type="button" onClick={handleClick}>
    Create post
- </div>
+ </button>

Use `cy.within()` instead of `cy.findAllBy*()`

If a page contains multiple elements with the same role and name (like multiple forms with "Save" button), instead of using cy.findAllBy*().first() or cy.findAllBy*().eq(<index>), try to use cy.within(). It will make your tests less dependent on implementation details. But better yet, try to avoid those situations in the first place.

- cy.findAllByRole("button", { name: "Save" }).eq(1).click();
+ cy.findByRole("form", { name: "User settings" }).within(() => {
+   cy.findByRole("button", { name: "Save" }).click();
+ });

Use cypress-plugin-steps

If you find yourself using code comments a lot in your Cypress tests, consider using cy.step() from cypress-plugin-steps instead. It will show the messages in the test log, and if your test fails, your scenario will be added to the error message, and it will be easier to pinpoint the failed command.

- // Go to posts
+ cy.step("Go to posts");
  cy.findByAltText("Menu").trigger("mouseover");
  cy.findByRole("link", { name: "Posts" }).click();

- // Delete post
+ cy.step("Delete post");
  cy.findByRole("button", { name: 'Open "My new post" menu' }).click();
  cy.findByRole("button", { name: 'Delete "My new post"' }).click();
  cy.findByRole("button", { name: "Yes" }).click();

If you liked this article, you should check out
Cypress Best Practices that are actually bad

Cypress Best Practices that are actually bad

Evgeny Orekhov — Sat, 01 Apr 2023 10:24:17 +0000

These are some of the best practices from the official Cypress documentation which are actually anti-patterns.

I'll explain why and give you better alternatives.

1. Use `data-*` attributes

Why it's bad

data-* attributes clutter your production code and make your tests be dependent on implementation details.

Better alternative: Cypress Testing Library

It doesn't require you to add extra stuff to your markup, makes your tests more abstract, and helps you improve accessibility.

Pro tips

1. Use ESLint to forbid `cy.get()` entirely

{
  "rules": {
    "no-restricted-properties": [
      "error",
      {
        "object": "cy",
        "property": "get",
        "message": "Use Testing Library query."
      }
    ]
  }
}

2. Follow Testing Library priority guide when writing queries

2. Use route aliases

Why it's bad

It still makes your tests flaky, and it makes them be dependent on implementation details.

Better alternative: UI assertions

Wait for something to appear in the UI, not for network requests to finish.

Bad:

cy.intercept("**/posts").as("publish");
cy.findByRole("button", { name: "Publish" }).click();
cy.wait("@publish");

Good:

cy.findByRole("button", { name: "Publish" }).click();
cy.findByRole("heading", { name: "My new post" }).to("be.visible");

Pro tip

Use ESLint to forbid `cy.wait()` entirely

{
  "rules": {
    "no-restricted-properties": [
      "error",
      {
        "object": "cy",
        "property": "wait",
        "message": "Use UI assertion."
      }
    ]
  }
}

If you liked this article, you should check out
More Cypress Best Practices

Prefer npm scripts to global commands

Evgeny Orekhov — Sat, 12 Jun 2021 13:18:13 +0000

Define npm scripts in your package.json:

"start": "ember serve",
"test": "ember exam --load-balance --parallel=4",
"lint": "npm-run-all --parallel --aggregate-output lint:**",

and use those scripts, don't use global commands.

Bad: ember test (yes, it's bad even if you see it in the official docs)

Good: npm test

There are several benefits to using npm scripts instead of global commands:

No chance of local vs global package version mismatch that can lead to inexplicable errors
No chance of using the wrong command and/or options (for example, the default command for running tests in Ember projects is ember test, but a project might use ember exam and/or additional options like --load-balance --parallel=4)
No need to remember specific commands for each type of project, because npm start and npm test are standard commands used by virtually every JavaScript project, be it an Ember project, a React project, or an Express project
No need to install global packages, keep track of their versions, and update them

If you really need to run a one-off command, use npx, it will protect you from local vs global package version mismatch (because it uses local package if it detects one):

npx prettier --write .

Use 👍 more often

Evgeny Orekhov — Wed, 26 Aug 2020 17:25:54 +0000

Agree with a GitHub comment? Spare a second of your time and give that comment a 👍. It can make the author of the content feel good and encourage them to contribute more.

Want that issue to be resolved sooner? Give it a 👍. It's often used by maintainers for prioritizing issues.

Some advice:

favor 👍 over ❤️/🎉/🚀 for GitHub issues, it will make prioritizing issues easier to do for maintainers (GitHub UI allows you to sort issues only by a particular reaction)
use 👎 less often (or don't use it at all), it can make the contributor feel bad and even discourage them from contributing
never write a comment that just says "+1" or "👍", use the 👍 reaction

Use 👍 more often.

eslint-config-hardcore – 17 plugins, 500 rules, and counting

Evgeny Orekhov — Mon, 22 Jun 2020 17:37:47 +0000

eslint-config-hardcore is a framework-agnostic "batteries included" config that aims to enable as many plugins and rules as possible to make your code extremely consistent and robust. It uses Prettier code style and autoformats your code with eslint-plugin-prettier.

There are dozens of great ESLint plugins out there. Did you know that there is a plugin that can optimize your regexes for you? Or did you know that ESLint can validate *.json files? This config allows you to gain the power of all those awesome plugins with a single npm install.

Fun (and useful) fact: you can use typescript-eslint for linting your JavaScript code. That's right, you can take advantage of typescript-eslint's type-aware rules, like @typescript-eslint/naming-convention and @typescript-eslint/prefer-optional-chain, without the need to switch to writing TypeScript. Use the hardcore/ts-for-js config for that.

Also, did you know that when you enable an ESLint rule with "rule-name": "error", you don't get all the benefits the rule can provide? Many rules have advanced options that are disabled by default. For example, the no-unneeded-ternary rule has the defaultAssignment option that can enforce using foo = bar || default instead of foo = bar ? bar : default. And the no-param-reassign rule allows you to modify parameter properties by default, which is considered a bad practice. This config uses those stricter options whenever it makes sense.

Back in 2016, when I started compiling this config, it was helping me begin my JavaScript journey. I was using it on small projects, and it was helping me avoid many JavaScript pitfalls. Over the years it grew and proved itself as an extremely useful tool for all kinds of projects, both backend and frontend. Now, I can't imagine what I would do without it and how much more painful our code reviews would be. And I really want to avoid any kind of nitpicking in pull requests. Let ESLint catch (and most of the time autofix!) all problems early.

The funniest thing: 500 rules are still not enough. We still spend time in code reviews catching issues and inconsistencies, especially when there are new developers on the team. So, expect to see more and more plugins and rules in the config in the future.

Let me know what you think. Try it out. Suggest more plugins.

Hacker News thread: https://news.ycombinator.com/item?id=23602860

Forem: Evgeny Orekhov

More Cypress Best Practices

Use eslint-plugin-cypress

Use UI assertions to reduce test flakiness

Use UI assertions to reduce screenshot flakiness

Use functions to create reusable commands

Make production code more accessible

Use cy.within() instead of cy.findAllBy*()

Use cypress-plugin-steps

Cypress Best Practices that are actually bad

1. Use data-* attributes

Why it's bad

Better alternative: Cypress Testing Library

Pro tips

1. Use ESLint to forbid cy.get() entirely

2. Follow Testing Library priority guide when writing queries

2. Use route aliases

Why it's bad

Better alternative: UI assertions

Pro tip

Use ESLint to forbid cy.wait() entirely

Prefer npm scripts to global commands

Use 👍 more often

Some advice:

eslint-config-hardcore – 17 plugins, 500 rules, and counting

Use `cy.within()` instead of `cy.findAllBy*()`

1. Use `data-*` attributes

1. Use ESLint to forbid `cy.get()` entirely

Use ESLint to forbid `cy.wait()` entirely