DEV Community: Mike Cataldo

Cypress Tip: Don't Overuse the Visibility Assertion

Mike Cataldo — Fri, 26 Feb 2021 18:10:18 +0000

Cypress makes assertions easy with the should command and an intuitive way to leverage the ubiquitous Chai assertion library.

Let's say, for example, that our application is the Real World App and we need to assert that upon navigating to Home the avatar at the top left is visible. We could write the test like this:

describe('Home', () => {
  before('sign in and navigate to Home', () => {
    // ...
  })
  it('see avatar', () => {
    cy.get('#avatar')
      .should('be.visible')
  })
})

This is 🔥 fine, but on multiple occasions, I've seen an overuse of this visibility assertion. For example, when filling out a form field, you might assert visibility between the query and the action like this:

describe('Sign In', () => {
  before('navigate to Sign In', () => {
    // ...
  })
  it('sign in', () => {
    cy.get('#username')
      .should('be.visible')
      .type('iheartjs')
    cy.get('#password')
      .should('be.visible')
      .type('password')
    cy.get('button#sign-in')
      .should('be.visible')
      .click()
    // ...
  })
})

It makes sense why we might do this: to avoid interacting with an element before it's visible. However, this is usually unnecessary and could be considered bad practice.

First, it's unnecessary because of two implicit behaviors of Cypress: actionability assertions and command retry-ability. Cypress will not attempt to perform certain actions on an element unless it's visible. If it isn't visible, Cypress repeatedly retries this assertion until either the assertion passes and the next command is executed or the timeout is reached and it fails.
Now the test can be written this way:

describe('Sign In', () => {
  before('navigate to Sign In', () => {
    // ...
  })
  it('sign in', () => {
    cy.get('#username')
      .type('iheartjs')
    cy.get('#password')
      .type('password')
    cy.get('button#sign-in')
      .click()
    // ...
  })
})

Not only is there less code to manage, but now there's less noise in the Command Log!

To be clear, we're assuming that the example is not a component test; and while we want to ensure that a user is able to sign in by filling in the fields and clicking a button, we have other tests to ensure form components work as intended. In that vein, it could also be considered bad practice to assert visibility even if it were necessary for a working test.
The alternative? Assert visibility using the :visible selector (jQuery's extension to native CSS pseudo-classes).

When you run the iteration below, Cypress will only perform the action on the element until it's visible.

describe('Sign In', () => {
  before('navigate to Sign In', () => {
    // ...
  })
  it('sign in', () => {
    cy.get('#username:visible')
      .type('iheartjs')
    cy.get('#password:visible')
      .type('password')
    cy.get('button#sign-in:visible')
      .click()
    // ...
  })
})

While this isn't necessary in cases like this, in the real world, you might run into a situation where you need to make the assertion solely for the purpose of test resiliency or debuggability.

In addition to visibility, there are several other default assertions - like ensuring the element is not disabled - that Cypress makes to determine actionability. Check out the Cypress docs for more in-depth content.

Cypress Tip: Get the Cypress Dashboard App

Mike Cataldo — Wed, 03 Feb 2021 17:04:36 +0000

If you're familiar with the Cypress Dashboard, you might immediately suspect that I'm clickbaiting you, but stay with me!

In Chrome, there's a way to add shortcuts to ordinary sites (like dashboard.cypress.io) as "apps". Firefox calls these "site-specific browsers" but sadly they're dropping SSB and PWA support, while other Chromium-based browsers are making it more of a mainstay. Edge on Windows supports this feature and will soon allow you to manage/uninstall those apps just like native ones.

Why would we do this? If you're like me, you check on runs frequently throughout the day. You also have a lot of apps and Chrome tabs - like the dashboard - open (because you're uber-productive). Hunting around for the dashboard either takes longer than it should or you have to navigate there every time.

Do this now (trust me):

Open the Cypress Dashboard in Chrome
At the top right, click More (⋮)
Click More Tools
Click Create shortcut
Input Cypress Dashboard as the name for the shortcut
Check the Open as window checkbox
Click Create

Now getting to the Cypress Dashboard is as easy as opening and switching apps!

If you're not familiar with the Dashboard or if you haven't used it in a while, I suggest giving it a try - at least on the free tier. Check out the FAQ if you have a question. Cypress has been making a ton of improvements on it as of late (and more on the way), so it's a worthy investment. I love it!

Cypress Tip: In-Spec Functions

Mike Cataldo — Wed, 03 Feb 2021 17:00:04 +0000

Let's imagine you have a bunch of repeatable code in your tests:

it('should do this thing', () => {
  // ...
  cy.get('#thisElement')
    .then($el => {
      // some unusual hackery here
    })
  // ...
})
it('should do that thing', () => {
  // ...
  cy.get('#thatElement')
    .then($el => {
      // some unusual hackery here
    })
  // ...
})
it('should do another thing', () => {
  // ...
  cy.get('#anotherElement')
    .then($el => {
      // some unusual hackery here
    })
  // ...
})

What a mess, right? You might be tempted to immediately break this out into a custom command...

it('should do this thing', () => {
  // ...
  cy.get('#thisElement')
    .doSomething()
  // ...
})

...but it's not necessarily the best solution for a number of reasons. The alternative? I'm calling it an in-spec function. It's an abstraction in the form of a hoisted function contained in the spec file:

describe('some feature', () => {
  it('should do this thing', () => {
    // ...
    cy.get('#thisElement')
      .then(doSomething)
    // ...
  })
    // ...
})
function doSomething($el) {
  // some unusual hackery here
}

Here's why you might want to use an in-spec function:

Like an abstraction into a custom command, this will make your tests much easier to reason about, but if it's only required in a single spec, why bother with a command when you can use plain JavaScript?
It's hoisted from the bottom so that it's out of the way, but because it's in the spec, it's easier to access in the event you need to debug, update or refactor it.
If you need this function outside the spec, it's likely easier to prototype it as an in-spec function first. Then when it's working the way you want, you can convert it to a command.

Taking Control of Your Cypress Test Runs With Tags

Mike Cataldo — Fri, 29 May 2020 18:48:41 +0000

Intro

Cypress is a phenomenal end-to-end testing tool. It's certainly not perfect but it's being updated consistently and it's expandable with plugins. I recently came upon a problem that required more granular control over my test runs than Cypress provides out of the box. Using our imagination, we'll take a similar journey to what I believe is a sweet solution to a problem you'll likely have. Let's go!

Problem

Imagine you have a great set of Cypress tests for your calculator app, perfectly organized by feature:

cypress
└───integration
│   └───add
│   │   │   add.spec.js
│   └───subtract
│   │   │   subtract.spec.js
│   └───multiply
│   │   │   multiply.spec.js
│   └───divide
│   │   │   divide.spec.js

Within each of these spec files are several tests:

// add.spec.js
it('add two numbers', () => {
 ...
})
it('add three fractions', () => {
 ...
})

// subtract.spec.js
it('subtract a negative number from a positive number', () => {
 ...
})
it('subtract two whole numbers', () => {
 ...
})

You get the idea.

The time it takes to test your calculator app end-to-end with Cypress is a lot longer than your unit tests take so you run them nightly. In an effort to catch bugs sooner, you and your team have determined that a certain set of tests need to be executed as part of your continuous integration pipeline. What's the best way to implement this?

Solution

You figure out your best course of action through an iterative process:

Good Solution - Separating Tests

First, you create important-tests.spec.js and move all the relevant tests into that file. You considered copying the tests but didn't want the hassle of keeping them in sync.
Then you run Cypress like this:

$ npx cypress run --spec 'path/to/important-tests.spec.js'

Easy enough, but you soon find out that maintenance is tricky because you now have double the number of files for each feature you need to maintain tests for. While this solution works, the additional complexity and cognitive load are too significant to scale effectively.

Better Solution - Tagging Tests

You discover a great plugin cypress-select-tests developed by Cypress' own Gleb Bahmutov, that provides a way to select or grep the specific tests you want to run.

Setup

Install:

$ npm install --save-dev cypress-select-tests

Update your plugins/index.js file:

import selectTestsWithGrep from 'cypress-select-tests/grep'
export default (on, config) => {
  on('file:preprocessor', selectTestsWithGrep(config))
}

Now running tests like this:

$ npx cypress run --env grep='fraction'

will execute only tests that contain fraction in the title. Sweet!

Tagging

The tests that need to run in CI are titled,

add three fractions
subtract two whole numbers
divide by zero
subtract fractions

You ask yourself,

What search term will result in only these tests running?

and find that there aren't any, so you toy around with the idea of adding one:

ci divide by zero
important: divide by zero
divide by zero, important
divide by zero, #important

Settling on the last format makes sense to you because it's not ambiguous, it's out of the way and, and most importantly, it's distinguishable from the other text, which reduces the risk that it'll be casually edited or a test that happens to have the term important in it won't be included in the run unintentionally. Phew!

Finally

Finally, running Cypress like this:

$ npx cypress run --env grep="#important"

results in a run - containing really important tests - that can be added to your pipeline so you can find critical bugs sooner without adding significant complexity to your workflow.

Conclusion

Many thanks to Gleb Bahmutov for his work on cypress-select-tests. I hope this was helpful to you!

Cypress 4.6.0 is Out...And Brings a Surprise New Feature!

Mike Cataldo — Fri, 22 May 2020 17:21:38 +0000

The Cypress team is still hard at work (per usual), bringing us regular releases. The latest iteration of Cypress (4.6.0) is out, and with it comes a surprising feature. It's something that I always wanted but didn't think was even possible, so I never asked for it or tried to build it out myself.

I'll give it to you straight from their Changelog:

Errors in the Test Runner now display a code frame to preview where the failure occurred with the relevant file, line number, and column number highlighted. Clicking on the file link will open the file in your preferred file opener and highlight the line and column in editors that support it.

So imagine for a moment the test runner shows a test failed at the cy.get() command, perhaps because you got the selector wrong. It happens to the best of us. Below the usual stack trace and message, Timed out retrying: Expected to find element: #login, but never found it., is a code frame which shows the line in your spec containing the failing command and a couple of lines of surrounding code for context. That's cute. At this point you'd have to go back to your editor and find the file and line where the failure occurred so you can start fixing it. But - at the top of the code frame is the relative path to the spec file (that you created in VSCode). And - here's the best part - clicking on that file opens it in VSCode with the offending line highlighted and your cursor in the precise spot where you need to make the correction. Pretty sweet, right?

Here it is in action:

This issue was created over a year ago, so completion of this is a testament to the diligence of the Cypress team in delivering an amazing, ever-evolving product.

In addition to regular updates, Cypress also comes with outstanding documentation if you want instructions to set up the File Opener Preference or how Cypress Errors work in general.

Enjoy this new feature and be sure to share your feedback with the Cypress team.

Static Analysis: What Is It and Why Is It Important?

Mike Cataldo — Wed, 20 May 2020 21:27:02 +0000

You're likely familiar with the concept of a code review: scrutinizing code by visual inspection, without the assistance of automated tools. You know manual processes are prone to human error and you'd jump at the opportunity to automate some of that process if you could, right? Enter static analysis:

In short, static analysis can:

provide an understanding of the code structure
help to ensure that the code adheres to a set of standards
and reveal errors that don't manifest themselves until disaster strikes
- which could be weeks, months or years post-release

Types of Static Analysis & Tooling

Automated tools can assist developers in carrying out different types of static analysis, loosely defined as linting, formatting and type-checking.

Linting - ESLint

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code, with the goal of making code more consistent and avoiding bugs

High-level Overview

ESLint statically analyzes your code to quickly find problems
- it's built into most editors like VSCode
- it can be run as part of a continuous integration pipeline
Some problems are fixed automatically
- fixes are syntax-aware
  - you won't experience errors introduced by traditional find-and-replace algorithms
And it's customizable to work exactly the way you need it for your project
- you can write your own rules that work alongside ESLint's built-in rules
- there are plenty of valuable plugins (rulesets written by others) to save you time

Example

Given this single line of code:

var foo = bar;

ESLint would output the following messages:

1:5 - 'foo' is assigned a value but never used. (no-unused-vars)
1:11 - 'bar' is not defined. (no-undef)

That output is a product of the recommended configuration which enforces rules no-unused-vars and no-undef (along with many others) that can be reconfigured to show a warning instead of an error or even be turned off completely.

Beyond initial setup and configuration, linting your entire codebase is easy:
$ npx eslint .

To lint React jsx files:
$ npx eslint --ext .jsx .

ESLint can be used to enforce standards around formatting with very fine control - down to the character. Even the whitespace around your code can be scrutinized! Other more opinionated formatting tools are designed to avoid this sort of bike-shedding.

Code Formatting - Prettier

Prettier reformats your code in a way that's more readable and consistent. While being a stickler for code style can seem unfruitful, there are some hidden code-quality gems to be found. Here's an example:

Example

const a = false
const b = false
const c = true
const d = a && b || c

If you don’t remember the order of operations of && and || - or you don’t trust that all developers on the team do - in order to get the value of d, then a bug could get introduced when this get refactored.

Formatting the code with Prettier results in this:

const a = false
const b = false
const c = true
const d = (a && b) || c

The extra parentheses are helpful even if you do know the order of operations. If by chance you realize that wasn’t your intention, you can add the parentheses yourself and Prettier will leave it that way:

const a = false
const b = false
const c = true
const d = a && (b || c)

Code formatting can make the intent of your code more obvious, reducing cognitive load on the developer reviewing or refactoring the code.

By design, Prettier configuration is limited. This delegation is at the cost of finer control over formatting which can be achieved by using ESLint instead to format your code.

Type-checking - TypeScript

Trying to invoke an object that’s not a function results (unsurprisingly) in an error like this:

x is not a function

However this happens at execution time.

A static type checker allows you to specify what data type a variable is to ensure - at compile time - that it’s being used properly by adding syntax to JavaScript to follow that variable through the code.

You might be saying to yourself, but JavaScript is not a compiled language! - and you'd be right! But TypeScript's compiler can be used to type-check your code - whether it's TypeScript or JavaScript.

Example

This code contains a bug:

function getFullName(customer) {
  const {
    name: {first, middle, last},
  } = customer
  return [first, middle, last].filter(Boolean).join(' ')
}
getFullName({first: 'John', middle: 'A', last: 'Smith'})

Adding type-checking helps us find the bug automatically:

type Customer = {
  name: {
    first: string,
    middle: string,
    last: string,
  },
}
function getFullName(user: Customer): string {
  const {
    name: {first, middle, last},
  } = customer
  return [first, middle, last].filter(Boolean).join(' ')
}

Here’s the output:
Argument of type '{ first: string; middle: string; last: string; }' is not assignable to parameter of type 'Customer'.2 Object literal may only specify known properties, and 'first' does not exist in type 'Customer'.(0123)
Type-checking can be adopted incrementally:

with Babel
- babel-preset-typescript
with a supported subset of JSDoc annotations
- Type Checking JavaScript Files

Conclusion

Static analysis should be an arrow in every JavaScript developer's quiver. In addition to manual and automated testing, it will give you more confidence that you're shipping quality code.