Forem: Walmyr

Building and Testing a Language Detector App

Walmyr — Tue, 04 Mar 2025 01:51:56 +0000

Introduction

In today's globalized world, it is essential for web applications to cater to users from different linguistic backgrounds. In this blog post, we will explore a simple language detector app that displays a message based on the user's browser language settings. Additionally, we will walk through the process of testing this app using Cypress, a powerful end-to-end testing framework.

Understanding the Language Detector App

The language detector app is a basic HTML and JavaScript application that detects the browser's language settings and displays a corresponding message. Below is the content of the index.html file, which forms the core of the app:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Language Detector</title>
    <style>
      body {
        font-family: Arial, sans-serif;
        text-align: center;
        padding: 50px;
      }
    </style>
  </head>
  <body>
    <h1 id="message"></h1>
    <script>
      // Define translations
      const translations = {
        "en": "Hello! Your browser is set to English.",
        "es": "¡Hola! Tu navegador está configurado en Español.",
        "fr": "Bonjour! Votre navigateur est défini sur Français.",
        "pt": "Olá! Seu navegador está definido para Português."
      };

      // Detect browser language
      const userLang = navigator.language || navigator.languages[0];
      const langCode = userLang.split('-')[0]; // Get base language code (e.g., 'en' from 'en-US')

      // Set message
      document.getElementById("message").textContent = translations[langCode] || "Hello! Your browser's language is not listed.";
    </script>
  </body>
</html>

How It Works

Translations: The app defines a set of translations for different languages (en, es, fr, pt).
Language Detection: It detects the browser's language using navigator.language or navigator.languages[0].
Message Display: Based on the detected language, it displays the corresponding message from the translations object. If the language is not listed, it displays a default message.

Testing the Language Detector App with Cypress

Cypress is an end-to-end testing framework that makes it easy to write, execute, and debug tests for web applications. In this section, we will create tests to verify that the language detector app displays the correct message based on different browser language settings.

Below is the content of the cypress/e2e/spec.cy.js file, which contains the Cypress tests:

describe('Lang App', () => {
  it("renders with the default language (en-GB)", () => {
    cy.visit('./index.html')

    cy.contains(
      'h1',
      'Hello! Your browser is set to English.'
    ).should('be.visible')
  })

  it("renders in en-US", () => {
    cy.visit('./index.html', {
      onBeforeLoad (win) {
        Object.defineProperty(win.navigator, 'language', {
          value: 'en-US'
        })
      }
    })

    cy.contains(
      'h1',
      'Hello! Your browser is set to English.'
    ).should('be.visible')
  })

  it("renders in es-ES", () => {
    cy.visit('./index.html', {
      onBeforeLoad (win) {
        Object.defineProperty(win.navigator, 'language', {
          value: 'es-ES'
        })
      }
    })

    cy.contains(
      'h1',
      '¡Hola! Tu navegador está configurado en Español.'
    ).should('be.visible')
  })

  it("renders in fr-FR", () => {
    cy.visit('./index.html', {
      onBeforeLoad (win) {
        Object.defineProperty(win.navigator, 'language', {
          value: 'fr-FR'
        })
      }
    })

    cy.contains(
      'h1',
      'Bonjour! Votre navigateur est défini sur Français.'
    ).should('be.visible')
  })

  it("renders in pt-BR", () => {
    cy.visit('./index.html', {
      onBeforeLoad (win) {
        Object.defineProperty(win.navigator, 'language', {
          value: 'pt-BR'
        })
      }
    })

    cy.contains(
      'h1',
      'Olá! Seu navegador está definido para Português.'
    ).should('be.visible')
  })

  it("renders with a not listed language (nb-NO)", () => {
    cy.visit('./index.html', {
      onBeforeLoad (win) {
        Object.defineProperty(win.navigator, 'language', {
          value: 'nb-NO'
        })
      }
    })

    cy.contains(
      'h1',
      "Hello! Your browser's language is not listed."
    ).should('be.visible')
  })
})

How the Tests Work

Default Language Test: The first test verifies that the app displays the correct message for the default language setting (English).
Specific Language Tests: The subsequent tests override the browser's language setting (navigator.language) to simulate different languages (en-US, es-ES, fr-FR, pt-BR) and verify that the app displays the correct message for each language.
Not Listed Language Test: The final test simulates a browser language setting that is not listed in the translations object (nb-NO) and verifies that the app displays the default message for unlisted languages.

Running the Tests

To run the Cypress tests, follow these steps:

Install Cypress: Ensure you have Cypress installed in your project. If not, you can install it using npm:

   npm install cypress --save-dev

Open Cypress: Open the Cypress test runner:

   npx cypress open

Run the Tests: In the Cypress test runner, click on the spec.cy.js file to run the tests.

Below the result of the tests executed in headless mode.

Lang App
    ✓ renders with the default language (en-GB) (42ms)
    ✓ renders in en-US (21ms)
    ✓ renders in es-ES (16ms)
    ✓ renders in fr-FR (16ms)
    ✓ renders in pt-BR (17ms)
    ✓ renders with a not listed language (nb-NO) (20ms)


  6 passing (166ms)

Conclusion

In this blog post, we explored a simple language detector app that displays a message based on the user's browser language settings. We also demonstrated how to write and run end-to-end tests for this app using Cypress. By following these steps, you can ensure that your app behaves correctly for users with different language settings.

Happy testing!

The whole code demonstrated in this blog post can be found at https://github.com/wlsf82/lang-app.

Would you like to learn Cypress in a hands-on course?

I introduce you to my course: 🌲 Cypress, from Zero to the Cloud ☁️.

I hope you like it!

Radical Simplicity

Walmyr — Wed, 30 Oct 2024 22:54:37 +0000

Radical simplicity in software design and development refers to the principle of creating systems, architectures, and user experiences that prioritize minimalism, clarity, and ease of use. The goal is to strip away unnecessary complexity and focus on the core functionality and essential features that deliver the most value to users. This concept advocates for simplifying code, design choices, and workflows to the point where the system is intuitive, easy to maintain, and efficient, both in performance and usability.

Key aspects of radical simplicity include:

Focus on Essential Features: Developers avoid feature bloat by concentrating only on what truly matters to the user or business goals. Every additional feature or element is carefully scrutinized for its necessity.
Minimization of Complexity: The architecture, code, and design choices are streamlined. Complex interdependencies and over-engineered solutions are avoided, ensuring that systems are modular, decoupled, and easy to reason about.
Maintainability: Simple designs often lead to cleaner codebases that are easier to maintain, extend, and debug. It enables new team members to onboard quickly and reduces the technical debt over time.
User-Centered Design: In the front-end and UX design, radical simplicity means creating interfaces that are easy to navigate and understand, reducing cognitive load for the user. The user experience should feel natural and require minimal instructions.
Iterative Improvement: Radical simplicity is often achieved through continuous iteration, where unnecessary complexity is stripped away in each cycle, with the aim of achieving an elegant, focused solution.

By embracing radical simplicity, teams can create systems that are not only highly functional but also resilient, adaptable, and scalable over time.

Radical simplicity in the context of Cypress web test automation

In the context of web test automation, radical simplicity involves creating tests and testing strategies that are easy to implement, maintain, and scale. When using Cypress as a testing framework, applying the concept of radical simplicity can result in more efficient, reliable, and maintainable test suites. Here’s how this principle manifests in Cypress-based test automation:

1. Minimalistic Test Design

Radical simplicity in Cypress test design encourages writing concise, focused tests that target core functionality. Rather than bloating tests with unnecessary steps or covering too many aspects in a single test, Cypress allows you to break tests into smaller, more manageable pieces. Each test should focus on a specific part of the application, reducing complexity and making tests easier to understand and debug.

Example: Instead of a single, long test that checks multiple features of a page, split it into smaller tests, each checking one feature. This improves readability and helps isolate failures.

2. Declarative Testing with Cypress

Cypress’s syntax and API are inherently simple and declarative. Its commands mirror the way users interact with web applications, making tests more intuitive. This aligns well with the principle of radical simplicity, as tests are often straightforward to write and read.

Example: Cypress provides commands like cy.get() and .click() that map directly to user actions, allowing tests to be written in a way that closely mirrors the user experience.

3. Reducing Setup Complexity with Auto-Retries

Cypress automatically retries assertions and commands until they pass or fail, which eliminates the need for adding explicit waits or complex timing logic to your tests. This simplifies the overall structure of tests by reducing the need for handling asynchronous code, allowing tests to focus on core functionality.

Example: Instead of adding cy.wait(1000) to ensure an element appears, Cypress will automatically retry a cy.get() command until the element is available or a timeout is reached. This keeps the code clean and simple.

4. Simplified End-to-End (E2E) Testing

Cypress simplifies E2E testing by running directly in the browser and having access to real-time feedback from the application under test. This eliminates the complexity of setting up separate drivers or configuring external tools for browser automation (as with Selenium), leading to simpler, more straightforward E2E tests.

Example: With Cypress, there is no need to install additional browser drivers or run separate services for executing tests. Everything runs locally in the same environment, reducing setup and potential points of failure.

5. Maintainable Test Suites through Best Practices

Cypress encourages the use of maintainable patterns like fixtures, and custom commands, which adhere to the principle of radical simplicity by keeping test code modular, reusable, and easy to update.

Example: Using fixtures for test data reduces duplication and centralizes the management of test data, making it easier to update when changes occur. Similarly, custom commands allow the encapsulation of repetitive sequences of commands, improving code readability and reducing redundancy.

6. cy.intercept for API interception

The cy.intercept() command simplifies GUI testing and network stubbing in Cypress, allowing for the interception and manipulation of network requests without adding external mocking libraries or complex setup. This keeps test logic clear and focused on testing application behavior, rather than managing network dependencies.

Example: Instead of setting up a mock server or waiting for real API responses, cy.intercept() allows you to simulate different responses directly in the test, making GUI testing both simpler and faster.

7. Error Handling and Debugging

Cypress provides automatic screenshots and videos on test failures, besides the Test Replay feature, which radically simplifies debugging. Developers don’t need to add extra logging or error-handling code in the tests to troubleshoot. This helps keep the tests simple while still being able to efficiently diagnose issues when they occur.

Example: When a test fails, Cypress provides a snapshot of the application state at the point of failure. This eliminates the need for extra boilerplate code to capture logs or states during test execution.

8. Integrated Assertions

Cypress has built-in assertions, such as checking for visibility, text content, and attributes, which simplifies the testing process. Instead of using external assertion libraries or verbose assertions, Cypress integrates these directly into its chainable commands, keeping the test code minimal and easier to read.

Example: Assertions like cy.contains('button', 'Submit').should('be.visible') are built into the Cypress command chain, allowing for a more streamlined syntax without the need for external libraries or excessive boilerplate code.

9. Simplified CI/CD Integration

Cypress is designed to integrate seamlessly with CI/CD pipelines. Its architecture, combined with simple configurations for parallel testing, reporting, and failure handling, reduces the complexity typically associated with setting up test automation in continuous integration environments.

Example: Cypress provides easy integration with services like GitHub Actions, CircleCI, and others, ensuring that tests can be run consistently and reliably without having to manually configure browsers, dependencies, or parallel execution strategies.

Conclusion

By leveraging Cypress’s design and capabilities, you can achieve radical simplicity in web test automation. The framework’s emphasis on minimal setup, intuitive commands, and modular test patterns aligns with the core idea of focusing on what’s essential, eliminating unnecessary complexity, and creating a sustainable and maintainable test suite. This allows teams to focus on delivering high-quality software without being bogged down by the intricacies of a complex testing setup.

Radical simplicity is a guiding principle that transcends specific tools, extending to how we approach software design, development, and testing as a whole. Embracing radical simplicity means creating systems that prioritize clarity, functionality, and ease of use while reducing unnecessary complexity. By focusing on essential features, minimizing architectural and code complexity, and centering on user experience, teams can build software that is not only resilient and scalable but also intuitive and accessible to users. Whether applied to development, testing, or user interface design, radical simplicity fosters maintainability, adaptability, and efficiency, helping teams create lasting, high-impact solutions that align with both immediate needs and long-term goals.

Test Design: What Everyone Should Know About Test Automation

Walmyr — Sun, 13 Oct 2024 01:25:54 +0000

How solid test design turns automation into a trustworthy quality signal

In the world of test automation, success isn't just about writing tests that pass or fail—it's about crafting solutions that are fast, reliable, maintainable, and scalable. Effective test automation is built on fundamental principles that ensure tests aren't just solving the problems of today but are also ready to tackle the challenges of tomorrow. Here, we’ll dive into what I call The Elements of Test Design—15 key principles that, when applied, will help you design efficient and future-proof test automation systems.

1. Suite, Sub-suite, and Test Cases’ Descriptions

Clarity in your test suite hierarchy and descriptions is foundational. Every suite, sub-suite, and test case should have a purpose that is clear at a glance. Descriptive and meaningful names help teams quickly understand what’s being tested and why. Think of this as your first layer of communication—tests should tell a story about the system’s behavior.

2. Test Levels

Different types of tests serve different purposes. Unit tests, integration tests, end-to-end tests, and performance tests each focus on specific layers of the application. Effective test automation design requires a strategic approach to layering these test levels. Too much focus on end-to-end tests can lead to slow, fragile test suites, while too much emphasis on unit tests can miss critical system-wide behaviors. The goal is to strike a balance that maximizes coverage while maintaining test suite stability and speed.

3. Abstractions

Abstractions are crucial to prevent repetitive code and reduce maintenance costs. Instead of repeating the same logic in multiple places, modularize common functionality and group related behaviors into reusable modules. This principle simplifies test design, enhances reusability, and allows you to focus on what’s truly important: the behavior under test. Modules help keep the test code DRY (Don’t Repeat Yourself) while allowing you to manage complexity in a clean, structured way.

4. Assertions

Assertions verify that the expected outcome matches the actual result. A strong test should have precise assertions that validate the critical behavior of your system. Avoid testing too many things at once, as it can lead to unclear failure points. Each test should focus on verifying a specific aspect of the application to make failures more diagnosable.

5. Independence

Tests should be independent, meaning the outcome of one test should not depend on the result or state of another. This principle is often overlooked, leading to fragile test suites that break when the order of execution changes. Independence ensures that each test can be run in isolation, which makes parallel execution possible, speeding up the test suite significantly.

6. Infrastructure and Environments

The test environment should closely mimic production to catch real-world issues. Managing infrastructure is a complex but necessary aspect of test automation. With tools like Docker or cloud-based services, it's possible to create scalable, disposable environments for testing. By using infrastructure-as-code and environment automation, you can ensure consistency and reduce “it works on my machine” issues.

7. Tools

Choosing the right tools for the job is vital. From test runners to assertion libraries and CI/CD tools, the test automation ecosystem offers numerous options. Pick tools that integrate well with your stack, support your goals (speed, maintainability, etc.), and align with the skill set of your team. But remember, tools are just enablers—the core of good test design remains the underlying principles.

8. Accessibility

Testing accessibility is often an afterthought but shouldn’t be. As more teams adopt accessibility-first approaches, ensuring your test automation framework can handle accessibility tests (such as checking for screen reader support or color contrast) is becoming increasingly important. Automated accessibility testing helps catch usability issues that may be missed during manual testing.

9. Testability

Good design considers how testable the application is. If it's difficult to test, it’s a sign that the code itself may need refactoring. By improving the testability of the system, such as using dependency injection or exposing APIs specifically for testing, you can make your application easier to validate and more robust.

10. Security

Security tests ensure that your application is not only functional but also safe from potential vulnerabilities. Automation can cover common security concerns like SQL injection, XSS attacks, or unauthorized access. One critical aspect is ensuring that sensitive data, such as passwords or API keys, is never versioned or exposed in your code repository. Make sure to use secure variables in your CI/CD pipeline and tools, and automate the scanning of your codebase for known vulnerabilities. Additionally, it's essential to incorporate automatic patching mechanisms that can address security vulnerabilities as they arise.

11. Tests' Size

The size of tests matters. Larger tests tend to be slower and more brittle, especially if they cover too much ground. A key principle in test design is to keep tests as small as possible while still validating the desired behavior. This helps to reduce the noise in failure reports and ensures faster execution, which is critical for maintaining a fast feedback loop.

12. Conventions

Adopting conventions in your test design leads to consistency across the test suite. Whether it’s naming conventions, file structures, or coding style, following agreed-upon patterns makes the test suite easier to navigate and maintain, particularly when scaling the test coverage over time.

13. The 3A Pattern (Arrange, Act, Assert)

The AAA pattern—Arrange, Act, Assert—provides a clean and simple way to structure your tests. By clearly separating the setup (Arrange), the action being tested (Act), and the validation (Assert), you ensure that tests are readable and organized. This structure makes it easier to see what’s being tested and why, while helping to avoid test logic creeping into setup or validation phases.

14. Performance Optimizations

Performance matters in test automation. Over time, as test suites grow, execution times tend to increase. To combat this, it’s crucial to regularly optimize tests for speed. Consider parallel execution, optimizing setup, and eliminating unnecessary waits or redundancies. Performance optimizations can also involve revisiting test levels and ensuring that only critical scenarios are covered in the more expensive end-to-end tests, while unit tests handle most validations.

15. Test Stability and Reliability

A test suite is only valuable if teams can trust its results. Tests must be stable, deterministic, and resilient to non-functional changes such as timing fluctuations, data noise, or environmental variations. Flaky tests—those that fail intermittently without real defects—erode confidence and are quickly ignored or disabled, undermining the entire automation effort. Designing for stability means minimizing dependencies on unstable elements, avoiding unnecessary waits, controlling test data, and favoring deterministic assertions. Equally important, stable tests should require minimal maintenance as the system evolves, changing only when behavior truly changes. The ultimate goal is to provide fast, reliable feedback that teams can confidently depend on to make decisions.

Solving Complex Test Automation Challenges with Simplicity

By applying The Elements of Test Design, you can address complex test automation challenges with simple yet effective strategies:

Balance Test Levels: Don’t overload your test suite with slow and fragile end-to-end tests. By leveraging unit and integration tests for most validations and reserving end-to-end tests for critical paths, you reduce flakiness while maintaining both speed and coverage.
Abstract Intelligently: Use abstractions to reduce duplication, but don’t over-engineer. Simple, behavior-focused abstractions not only improve maintainability but also contribute to test stability by centralizing changes and reducing inconsistent implementations across tests.
Optimize for Speed and Stability: Fast tests are important, but fast and flaky tests are useless. Continuously evaluate your test suite for performance bottlenecks and sources of instability, such as unnecessary waits, race conditions, or environment-dependent behavior. Speed should amplify reliability, not compromise it.
Design for Reliability: Treat flaky tests as production bugs. Invest in deterministic test data, controlled environments, and clear assertions that fail only when behavior truly breaks. A reliable test suite builds trust and ensures failures are meaningful and actionable.
Ensure Independence: Test failures should always reflect real issues, not hidden dependencies or leaked state. Independence improves parallelization, simplifies debugging, and is a key factor in achieving long-term test stability.
Use the Right Tools: Let the problem drive the tool selection. Favor tools and frameworks that promote determinism, good diagnostics, and easy isolation of tests. A tool that makes tests easy to write but hard to stabilize will slow teams down in the long run.

By embracing these principles, you’ll create a test automation suite that is not only robust, scalable, and maintainable, but also trusted. Stability and reliability transform automation from a safety net into a decision-making engine, giving teams the confidence to move fast without sacrificing quality.

This holistic approach to test design turns your automation efforts into a strategic advantage, ensuring you aren’t just testing for today but building a system that can adapt and grow with the complexity of your application over time.

Hi, my name is Walmyr, and I teach about test design to software professionals.

If you're interested in Test Design Training, reach out to me on LinkedIn, and let's talk.

Happy testing! 👋

This content was translated to Portuguese, and you can find the translated version at the Talking About Testing blog.

Logging into different environments with Cypress

Walmyr — Fri, 26 Jan 2024 06:30:00 +0000

Learn how to log into different environments with Cypress, protecting sensitive data, such as username and password

In another blog post of the Pinches of Cypress series, I wrote about how to change the baseUrl via the command line with Cypress.

But what about sensitive data, such as credentials for authentication in the same application, deployed in different environments? That's precisely what I'll teach you in this content!

Let's imagine an application deployed in three different environments, each with its specific credentials:

Local (your computer)
Staging
Production

The user's email and password are required to log into the application (in any of the environments).

Let's also assume that in the Cypress configuration file (cypress.json, or cypress.config.js – from version 10 onwards), the baseUrl points by default to the local development environment, as shown below:

{
  "baseUrl": "http://localhost:3000"
}

Above is the configuration file before Cypress version 10.

// cypress/config/cypress.config.js (from version 10 onwards)

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:3000'
  }
})

Above is the configuration file from Cypress version 10 onwards.

However, the staging and production environments have the following URLs, respectively:

https://example.staging.com
https://example.com

Let's also assume that in the package.json file, we have the following scripts for running tests in each specific environment:

"scripts": {
  "test": "cypress run",
  "test:staging": "cypress run --config baseUrl=https://example.staging.com --env environment=staging",
  "test:prod": "cypress run --config baseUrl=https://example.com --env environment=prod"
}

The test script executes the tests against the local environment since the baseUrl is not overridden.

In the test:staging and test:prod scripts, the baseUrl is overridden via the command line. Additionally, we pass a variable called environment with a value that identifies each environment (staging and prod).

In the local environment, we can have an unversioned file (included in the .gitignore file) called cypress.env.json, which would have the following structure:

{
  "LOCAL_USER": {
    "email": "local@user.com",
    "password": "the-password-of-the-above-user"
  },
  "STAGING_USER": {
    "email": "some-user@example.staging.com",
    "password": "the-password-of-the-above-user"
  },
  "PROD_USER": {
    "email": "another-user@example.com",
    "password": "the-password-of-the-above-user"
  }
}

Note: I also recommend creating a versioned file called cypress.env.example.json with example values so other team members can use it as a template for creating their own unversioned cypress.env.json files.

Note 2: In a continuous integration environment, such values (STAGING_USER and PROD_USER) could be set as secrets, with the prefix CYPRESS_, i.e., CYPRESS_STAGING_USER and CYPRESS_PROD_USER, with their respective values.

Now that we have the credentials let's implement a custom command for logging in based on the environment where the tests are being executed.

// cypress/support/commands.js

Cypress.Commands.add('login', () => {
  cy.log(`Logging into the ${Cypress.env('environment') ? Cypress.env('environment') : 'local'} environment`)

  if (Cypress.env('environment') === 'staging') {
    Cypress.env('user', Cypress.env('STAGING_USER'))
  } else if (Cypress.env('environment') === 'prod') {
    Cypress.env('user', Cypress.env('PROD_USER'))
  } else {
    Cypress.env('user', Cypress.env('LOCAL_USER'))
  }

  cy.visit('/login')

  cy.get('[data-cy="emailField"]')
    .should('be.visible')
    .type(Cypress.env('user').email, { log: false })
  cy.get('[data-cy="passwordField"]')
    .should('be.visible')
    .type(Cypress.env('user').password, { log: false })
  cy.contains('button', 'Login')
    .should('be.visible')
    .click()
})

In the login custom command, we dynamically set the user variable depending on the environment passed via the command line in the npm script. Thus, we can use this variable in commands that enter the user's email and password.

Additionally, we log the phrase "Logging into the [environment] environment" in the Cypress command log, depending on the environment where the tests are running. If the environment variable is passed, we use it; otherwise, the default is the local value.

So, if the value of the environment variable is, for example, staging, the following would be "printed" in the Cypress command log:

Logging into the staging environment.

And the login test would look something like this:

// cypress/integration/login.spec.js (before Cypress version 10)
// or cypress/e2e/login.cy.js (from Cypress version 10 onwards)

it('logs in', () => {
  cy.login()

  cy.get('[data-cy="avatar"]')
    .should('be.visible')
})

As you can see, in the actual test, we only call the custom command cy.login, which authenticates the application with the correct credentials.

That's it! I hope you learned something new.

For more details on how Cypress works, I recommend reading the official documentation.

Did you like the content? Leave a comment.

This blog post was originally published in Portuguese at the Talking About Testing blog.

Would you like to learn Cypress in a hands-on course?

I introduce you to my newest course, 🌲 Cypress, from Zero to the Cloud ☁️.

I hope you like it, and happy testing!

Simulating Internet Outage and Recovery using Cypress

Walmyr — Fri, 26 Jan 2024 00:57:52 +0000

Unveiling Cypress's Power: Testing Internet Outages and Recoveries with Precision

Testing an application under various scenarios is crucial to ensure its robustness and user-friendliness.

One common yet challenging scenario is simulating internet outages and recoveries.

In this blog post, we'll explore a Cypress test that replicates this scenario, utilizing the powerful intercept command to manipulate network requests and responses.

This blog post was originated by the following test, from the Cypress Playground repository.

The Test Scenario

The test aims to simulate the internet going "down" and then recovering.

Let's walk through the code step by step to understand how it achieves this:

// Complete Code

it('simulates the internet going "down" then back "up"', () => {
  // Simulating Network Error
  cy.intercept(
    'GET',
    'https://jsonplaceholder.typicode.com/todos/1',
    { forceNetworkError: true }
  ).as('networkError')

  // Triggering the Request
  cy.contains('button', 'Get TODO').click()

  // Handling the Network Error
  cy.wait('@networkError')
  cy.contains(
    '.error span',
    'Oops, something went wrong. Check your internet connection, refresh the page, and try again.'
  ).should('be.visible')

  // Triggering Recovery
  cy.reload()

  // Simulating Successful Request
  cy.intercept(
    'GET',
    'https://jsonplaceholder.typicode.com/todos/1',
    { middleware: true }
  ).as('getTodo')

  cy.contains('button', 'Get TODO').click()

  cy.wait('@getTodo')
    .its('response.statusCode')
    .should('be.equal', 200)

  // Validating Result
  cy.contains('ul li', 'TODO ID: ').should('be.visible')
  cy.contains('ul li', 'Title: ').should('be.visible')
  cy.contains('ul li', 'Completed: ').should('be.visible')
  cy.contains('ul li', 'User ID: ').should('be.visible')
})

Breaking It Down

Let's break it down, so you can understand each piece of code step-by-step.

1. Simulating Network Error

cy.intercept(
  'GET',
  'https://jsonplaceholder.typicode.com/todos/1',
  { forceNetworkError: true }
).as('networkError')

In this section, we use the cy.intercept command to intercept any GET request to the specified URL (https://jsonplaceholder.typicode.com/todos/1). The interception is configured to force a network error (forceNetworkError: true). The interception is named 'networkError' using the as command, allowing us to wait for it later.

2. Triggering the Request

cy.contains('button', 'Get TODO').click()

This line simulates a user action by clicking a button with the text 'Get TODO.' This triggers the intercepted GET request, and Cypress will capture the interception labeled as 'networkError.'

3. Handling the Network Error

cy.wait('@networkError')

The cy.wait('@networkError') command pauses the test execution until the intercepted request labeled 'networkError' is completed. This ensures that the test waits for the network error response before proceeding.

cy.contains(
  '.error span',
  'Oops, something went wrong. Check your internet connection, refresh the page, and try again.'
).should('be.visible')

After the network error, the test expects to find a visible element with the specified error message. This asserts that the application responds appropriately to a network error, providing a user-friendly message.

4. Triggering Recovery

cy.reload()

This line reloads the page, simulating a user's attempt to recover from the network error.

5. Simulating Successful Request

cy.intercept(
  'GET',
  'https://jsonplaceholder.typicode.com/todos/1',
  { middleware: true }
).as('getTodo')

Here, we intercept the same GET request, but this time, we simulate a successful response ({ middleware: true }). The interception is named 'getTodo'.

For more details about the middleware property, I recommend reading about the interception lifecycle, directly from the Cypress official docs.

cy.contains('button', 'Get TODO').click()

Another user action triggers the successful request interception.

cy.wait('@getTodo')
  .its('response.statusCode')
  .should('be.equal', 200)

The test waits for the 'getTodo' interception and asserts that the response status code is 200, confirming the successful recovery.

6. Validating Result

The subsequent lines validate the presence of specific elements on the page, ensuring that the application displays the expected data after the recovery.

cy.contains('ul li', 'TODO ID: ').should('be.visible')
cy.contains('ul li', 'Title: ').should('be.visible')
cy.contains('ul li', 'Completed: ').should('be.visible')
cy.contains('ul li', 'User ID: ').should('be.visible')

These assertions check for the visibility of elements indicating that the application has successfully fetched and displayed the TODO details.

Conclusion

This Cypress test provides a comprehensive simulation of internet outage and recovery, allowing testers and developers to evaluate how an application responds to network errors.

Realistic scenarios, powered by Cypress commands like intercept, enable effective validation of application behavior under challenging conditions.

Finally, ensuring meaningful feedback and maintaining robustness are critical aspects of delivering a seamless user experience, even in the face of potential network issues.

Did you like the content? Leave a comment.

Would you like to learn Cypress in a hands-on course?

I introduce you to my newest course, 🌲 Cypress, from Zero to the Cloud ☁️.

I hope you like it, and happy testing!

Filtering the available browsers in Cypress

Walmyr — Thu, 03 Aug 2023 08:34:09 +0000

Learn how to define which browsers will be available to run tests with Cypress

Cypress is a web test automation framework that comes with everything you need to create automated tests without wasting time with configurations and other details.

Among its facilities, Cypress identifies which browsers are available on your computer, and when opened, you can select which browser you want to run the tests in, as shown in the image below.

As you can see, in addition to Chrome, Edge and Firefox browsers (available on my computer when I took this screenshot), there is also the Electron browser, which is the desktop version of Chrome.

You can also choose in which browser the tests will run in when running them in headless mode (the mode normally used in continuous integration).

To do so, just run cypress run --browser chrome, cypress run --browser edge, or cypress run --browser firefox.

Note: When running just cypress run, Cypress will run the tests by default in the Electron browser (the desktop version of Chrome).

Making only web browsers available to Cypress

Usually, web applications are used by their users in web browsers, rather than a desktop version of the browser, such as Electron.

Therefore, in order not to run the risk of running the tests in such a browser, we can remove it from the list of available browsers.

To do so, simply add the following implementation to the setupNodeEvents function defined in the e2e property of the Cypress configuration file (cypress.config.js).

setupNodeEvents(on, config) {
  return {
    browsers: config.browsers.filter(browser => browser.name !== 'electron')
  }
}

That is, from the Cypress configuration, we are getting the browsers and filtering them for all except electron.

In this way, when executing the cypress open command, the Electron browser will no longer be available, as shown in the image below.

And that way, we don't run the risk of accidentally testing the application in a browser that the real users of the application wouldn't use.

For a real-world example, see the following configuration file from the meal-suggestion project on GitHub.

Source: https://docs.cypress.io/guides/guides/launching-browsers#Customize-available-browsers

Curious and want to learn more about Cypress Testing Automation? Check out my courses on Udemy.

👋 Until next time, and happy testing!

This post was originally published in Portuguese at the Talking About Testing blog.

Testing copy to clipboard with Cypress

Walmyr — Fri, 09 Sep 2022 13:12:02 +0000

Learn how to read information saved in the browser window, such as what is held in the clipboard

Imagine a simple application with only a text input field, with a default value of Hello world, and a button called copy to clipboard, which, when clicked, copies the input text to that area, as the name suggests.

When clicked as soon as the application is visited, the text copied is Hello world.

However, when such a field is cleared, another text is typed, and the button is clicked again, the new text is copied.

And then you ask yourself.

How to test these scenario with Cypress?

Glad you asked because that's what I'm going to show you in this “Pinch of Cypress.”

The application code is summarized in the following index.html file.

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Copy to clipboard example page</title>
    <style>
      * {
        font-family: sans-serif;
      }
    </style>
  </head>
  <body>
    <h1>Copy to clipboard sample</h1>
    <input type="text" value="Hello World" id="copy-to-clipboard-input-field">
    <button onclick="copyToClipboard()">Copy to clipboard</button>
    <script>
      function copyToClipboard() {
        const copyText = document.getElementById("copy-to-clipboard-input-field")

        copyText.select() // Select the text field
        copyText.setSelectionRange(0, 99999) // For mobile devices

        // Copy the text inside the text field
        navigator.clipboard.writeText(copyText.value)
      }
    </script>
  </body>
</html>

And the test code in the following file cypress/integration/copyToClipboard.spec.js.

it('copies the input field text to the clipboard', () => {
  cy.visit('./index.html')

  cy.contains('button', 'Copy to clipboard').click()

  cy.assertValueCopiedToClipboard('Hello World')

  cy.get('#copy-to-clipboard-input-field')
    .clear()
    .type('Foo bar baz')

  cy.contains('button', 'Copy to clipboard').click()

  cy.assertValueCopiedToClipboard('Foo bar baz')
})

Cypress.Commands.add('assertValueCopiedToClipboard', value => {
  cy.window().then(win => {
    win.navigator.clipboard.readText().then(text => {
      expect(text).to.eq(value)
    })
  })
})

In the test, I first visit the application under test, i.e., the index.html file.

Then, I find the button with the text Copy to clipboard and click on it.

When the button is clicked, the default text of the input field must be copied to the clipboard, and therefore, I verify that the correct value has been copied through a custom command, which I will explain later.

Then I clear the input, type a different value and click the button again.

Finally, I verify that the new value has now been copied to the clipboard, replacing the previous one.

Now, let me explain in detail the custom command that verifies that the value was correctly copied to the clipboard.

The command receives as an argument the value to be compared, that is, the expected result.

In its implementation, I execute the cy.window() command, in which I chain the .then() command, passing to it a callback function, which takes the browser window (win) as an argument.

With access to the window (win), I access the navigator property, from there I access the clipboard property, and then I use the readText() function to read the text copied to the clipboard, where I chain another .then(), where in this case, the callback function receives the text contained in the clipboard as an argument, allowing me to check that the text is equal to the expected value.

And this is how I can test the value copied to the browser clipboard with Cypress.

See the test running in the gif below.

Also, see the complete code on GitHub.

Take the opportunity to leave it a ⭐!

Reference: https://www.w3schools.com/howto/howto_js_copy_clipboard.asp.

Did you like the content? Leave a comment.

Curious and want to learn more about Cypress Testing Automation? Check out my courses on Udemy.

👋 Until next time, and happy testing!

This post was originally published in Portuguese at the Talking About Testing blog.

cy.get() vs. cy.contains()

Walmyr — Mon, 08 Aug 2022 19:29:00 +0000

Get to know one of the differences between the commands `cy.get` and `cy.contains`

Here's a simple but helpful piece of information to better use Cypress and understand when to use one command or another.

Do you know the difference between the two lines of code below?

cy.get('tr:contains(User 1)')

cy.contains('tr', 'User 1')

They look quite similar, don't they?

However, they are actually different.

While cy.get gets one or more DOM elements.

cy.contains gets only one DOM element.

Here's an example where we need to combine cy.get with jQuery's contains selector instead of using cy.contains.

Just to reinforce.

cy.get('tr:contains(User 1)') // get ALL table rows which contain User 1 in their content

cy.contains('tr', 'User 1') // get the first table row which contains User 1 in its content

I hope you find this helpful information.

Did you like the content? Leave a comment.

Curious and want to learn more about Cypress Testing Automation?

Check out my online courses on Udemy.

👋 Until next time, and happy testing!

This content was translated to Portuguese and can be found on the Talking About Testing blog.

How to login programmatically with Cypress

Walmyr — Sun, 09 Jan 2022 23:42:57 +0000

Learn how to make your automated tests faster by authenticating via API

Automated graphical user interface tests must be independent of each other. In addition, such tests must relly as little as possible on the graphical user interface to reach the desired state for the test itself to take place.

It seems counter-intuitive, but that's precisely it.

From the graphical user interface, we should test it only once. More than that is waste.

However, in most web applications, the user must be authenticated to access certain functionality. So, how to authenticate such a user without going through the login page?

That's precisely what I will show you in this pinch of Cypress.

Note: It is worth remembering that this is just an alternative and that it may not be suitable for your use case. For more examples, I recommend reading the Testing Strategies section of the Cypress official documentation.

To ease the explanation, I will use a project I have recently contributed to — the BR Modelo Web.

Let's imagine the following test case.

// cypress/e2e/programmaticLogin.cy.js

it('successfully logs in programmatically', () => {
  cy.intercept('GET', `${Cypress.env('apiUrl')}/models?userId=*`)
    .as('getUserModels')

  cy.request('POST', `${Cypress.env('apiUrl')}/users/login`, {
    username: Cypress.env('userEmail'),
    password: Cypress.env('userPassword'),
  }).then(({ body }) => {
    cy.setCookie('sessionId', body.sessionId)
    cy.setCookie('userId', body.userId)
    cy.setCookie('userName', body.userName)
  })

  cy.visit('/#!/main')
  cy.wait('@getUserModels')
  cy.contains('h2', 'Models').should('be.visible')
}

Now, let's understand what this code does.

First, inside the test body, that is, inside the it block, I use the cy.intercept command. With such a command, I can “listen” 👂 to network calls, such as a GET request to the application's API URL that fetches the models of the logged-in user. Then I give an alias to that intercept. The alias is getUserModels.

Then comes the part where the programmatic authentication happens.

In this part, I use the cy.request functionality to make a POST request to the login URL, passing the username and password properties in the request body, both coming from variables (using the Cypress.env() functionality). I do this not to expose sensitive data.

Then, I chain to the cy.request() command a .then(), which takes as argument an arrow function, which takes as an argument the response's body of the cy.request(), using JavaScript's object destructuring.

In the body of this arrow function, I use the cy.setCookie() functionality, as the name suggests, to set some cookies based on the body of the request-response. These are precisely the cookies set when the user logs in via the graphical user interface.

With cookies set, I visit the application's homepage.

Finally, I do some checks.

First, I wait for the intercept request created earlier to occur, with cy.wait(), passing it the alias created earlier ('@getUserModels').

And then, I check that a particular element is visible (an h2 with the text Models), which is only visible to authenticated users, proving that the login was successful.

Done! 🎉

Attention: When testing a login functionality, it is recommended that such testing takes place via the graphical user interface. However, for all other features that require the authenticated user, use login programmatically and save a few seconds on each test!

Bonus - Custom Command

Since more than one test suite will need to login programmatically, we can move that logic to a custom command, which can be reused as many times as needed.

Here's what the test code would look like.

// cypress/e2e/programmaticLogin.cy.js

it('successfully logs in via GUI', () => {
  cy.intercept('GET', `${Cypress.env('apiUrl')}/models?userId=*`)
    .as('getUserModels')
  cy.loginViaAPI()
  cy.wait('@getUserModels')
  cy.contains('h2', 'Models').should('be.visible')
})

And the custom command.

// cypress/support/commands.js

Cypress.Commands.add('loginViaAPI', (
  email = Cypress.env('userEmail'),
  password = Cypress.env('userPassword')
) => {
  cy.request('POST', `${Cypress.env('apiUrl')}/users/login`, {
    username: email,
    password,
  }).then(({ body }) => {
    cy.setCookie('sessionId', body.sessionId)
    cy.setCookie('userId', body.userId)
    cy.setCookie('userName', body.userName)
    cy.visit('/#!/main')
  })
})

In the test, now all the logic of cy.request and cy.setCookie is abstracted. I just call the cy.loginViaAPI() command, and it manages to do what needs to be done to authenticate the user.

In addition to having the previous logic of programmatic login, the custom command can now also receive an email and password as arguments. However, if no arguments are passed, such values already have defaults coming from variables.

Also, I decided to move the visit to the home page to the custom command.

See the test running and authenticating without going through the login page. It looks like magic! 🪄

That's it!

I hope you enjoyed it.

Access the final version in this public repository on my GitHub profile.

Or the BR Modelo Web App project.

Take the opportunity to leave a star! ⭐

Did you like the content? Leave a comment.

Curious and want to learn more about Cypress Testing Automation? Check out my courses on Udemy.

👋 Until next time and happy testing!

This post was originally published in Portuguese at the Talking About Testing blog.

The importance of testability for web testing automation

Walmyr — Fri, 07 Jan 2022 16:39:22 +0000

Learn how to improve the readability of automated tests written with the Cypress framework

Does your team care about testability?

If so, this post is for you!

One way to check the testability of a web application is to inspect the frontend elements and verify if they have attributes added specifically to facilitate the automation of graphical interface tests, such as data-test, data-test-id, data-qa, data-cy, etc.

Imagine the following HTML form.

<!-- ./index.html -->

<form name="login-form">
  <label for="email">Email</label>
  <input type="email" name="email" id="email" data-test="email-field" required />
  <label for="password">Password</label>
  <input type="password" name="password" id="password" data-test="password-field" required />
  <button type="submit" data-test="login-button">Login</button>
</form>

As you can see, all the elements we need to automate such a form have data-test attributes.

This is an example of testability.

And why is this important?

When the frontend of a web application has attributes specifically created for testability purposes, there is less risk that changes to its logic or style will break the tests.

Now, let's look at a test (written with Cypress) that fills out such a form.

// cypress/integration/loginForm.spec.js

beforeEach(() => {
  cy.visit('./index.html')
})

it('successfully logs in', () => {
  const email = Cypress.env('userEmail')
  const password = Cypress.env('userPassword')

  cy.get('[data-test="email-field"]').type(email)
  cy.get('[data-test="password-field"]').type(password, { log: false })
  cy.get('[data-test="login-button"]').click()

  cy.contains('You\'re now logged in!').should('be.visible')
})

The test above makes use of such attributes, however, there is some repetition in the selection of elements, where the only part that changes are the values of the data-test attribute.

What if we could improve this?

Well, we can!

See the new version of the test below.

// cypress/integration/loginForm.spec.js

beforeEach(() => {
  cy.visit('./index.html')
})

it('successfully logs in', () => {
  const email = Cypress.env('userEmail')
  const password = Cypress.env('userPassword')

  cy.dataTest('email-field').type(email)
  cy.dataTest('password-field').type(password, { log: false })
  cy.dataTest('login-button').click()

  cy.contains('You\'re now logged in!').should('be.visible')
})

Cypress.Commands.add('dataTest', value => {
  return cy.get(`[data-test="${value}"]`)
})

Now, instead of all that repetition, we have a custom command that abstracts this logic, and the test itself is clean, passing to the .dataTest command the appropriate value depending on the element we want to select.

Note: Ideally, such custom command would be defined in the cypress/support/commands.js file, however, in this case I left it directly in the test file for teaching purposes.

See the test running.

That's it!

Did you like the content? Leave a comment.

Also, access the complete code on GitHub.

Curious and want to learn more about Cypress Testing Automation? Check out my courses on Udemy.

👋 Until next time and happy testing!

This post was originally published in Portuguese at the Talking About Testing blog.

How to create fixtures with random data using Cypress and faker

Walmyr — Wed, 13 Oct 2021 10:26:13 +0000

Random fixtures? Yes, it is possible!

One of these days, in the Cypress-BR group on Telegram, the following question came up:

Is it possible to put faker on a .json file?

The short answer is no.

But, it's possible to create a .json file dynamically, using the cy.writeFile functionality, and with the help of the faker library, make all data in this file dynamic.

Let's look at an example, creating a fixture for use in a test that mocks the backend and tests the frontend in isolation.

The application under test (AUT) is called Hacker Stories.

This application communicates with the Hackernews public API for listing stories.

However, as mentioned earlier, we will mock the API.

The test file is as follows.

// cypress/integration/hackerStories.spec.js

describe('Hacker Stories', () => {
  beforeEach(() => {
    cy.generateFixture()

    cy.intercept(
      'GET',
      '**/search?query=React&page=0',
      { fixture: 'stories' }
    ).as('getStories')

    cy.visit('/')
    cy.wait('@getStories')
  })

  it('renders 20 stories, then 19 when dismissing one', () => {
    cy.get('.item').should('have.length', 20)

    cy.get('.button-small').first().click()

    cy.get('.item').should('have.length', 19)
  })
})

Note that in the beforeEach hook, there is a custom command called generateFixture(). We'll see what this command does in a moment.

Also, notice that we are intercepting a request, which we will respond with a fixture called stories.

Afterward, we visit the AUT, wait for such mocked request to happen, and the test is executed, which verifies that there are 20 items in the list and that when removing the first one, 19 are left.

You might be curious about the implementation of the generateFixture() command, right?

There it goes.

// cypress/support/commands.js

Cypress.Commands.add('generateFixture', () => {
  const faker = require('@faker-js/faker')

  cy.writeFile('cypress/fixtures/stories.json', {
    'hits':Cypress._.times(20, () => {
      return {
        'title':`${faker.lorem.words(3)}`,
        'url':`${faker.internet.url()}`,
        'author':`${faker.name.firstName()} ${faker.name.lastName()}`,
        'num_comments':`${faker.datatype.number()}`,
        'points':`${faker.datatype.number()}`,
        'objectID':`${faker.datatype.uuid()}`,
      }
    })
  })
})

For the random data, we import faker to the command, using JavaScript's require function.

Then we use cy.writeFile, to write a file called stories.json in the cypress/fixtures/ directory. As a second argument, we pass an object, which will contain the value of that file.

Such an object will have a hits property, which is exactly what the frontend expects, and that property expects an array of objects.

We use lodash's .times functionality (which is bundled with Cypress), as it returns precisely an array.

Then the .times function runs 20 times to create 20 random stories, each with its title, url, author, num_comments, points, and objectID, using different functionalities offered by the faker library.

For an example of the created fixture, access this file.

Note: Since this fixture is dynamic, we must add it to the .gitignore file, cause we don't want to version it.

And so, we have a test that consumes a dynamically created fixture with random data. 🥳

That is, for each run, the fixture will be overwritten with new data.

I invite you to clone the project on your computer, install the dependencies following the documentation and then run the tests (both in interactive and in headless mode).

Access the complete project on GitHub.

Take the opportunity to leave a ⭐.

Note 2: As an alternative to the proposed solution, check out this other one, where instead of using fixtures, we overwrite the request response's body.

Did you like the content? Leave a comment!

Curious and want to learn more about Cypress Testing Automation? Check out my courses on Udemy.

👋 Until next time and happy testing!

This post was originally published in Portuguese at the Talking About Testing blog.

Best practices in test automation with Cypress

Walmyr — Mon, 27 Sep 2021 05:50:01 +0000

On July 31, 2021, I had the pleasure of participating in the Minas Testing Conference, where I spoke about How to create fast and robust automated tests with Cypress.

Note: The lecture was in Portuguese.

The talk was really cool, and I brought you a summary with each of the best practices, so you can apply it to your projects and make your tests faster and more robust.

Note 2: You can apply most of the best practices mentioned below regardless of the test framework being used, but some are specific to Cypress.

1. Independent tests

Automated tests must run in isolation, without the need for another test to run to create some state in the application under test.

The failure of one test shouldn't impact the results of other tests.

In addition, independent tests are easier to parallelize.

Tip: use the beforeEach hook when you need to perform repeated steps for all tests of a given describe or context.

2. Programmatic authentication

Logging in via the graphical user interface as a pre-condition for all tests is costly (in terms of execution time), and it makes the tests dependent on each other, which is a bad practice.

A disabled login button due to an HTML error, for example, shouldn't break an entire test suite.

By adding mechanisms to log in programmatically, you make tests faster and more independent.

3. State creation mechanisms

By creating such mechanisms, we ensure that tests are completely decoupled from each other, we don't need abstractions that add complexity to tests, such as Page Objects, and we guarantee fast and straight-to-the-point tests.

Examples of these mechanisms are API calls for creating resources, communication with the database via tasks, or running scripts at the operating system level.

4. data-* attributes

Adding attributes to front-end elements, such as data-test, data-testid, or data-cy, adds to the application what I call "testability," as these attributes are specifically created for testing purposes, decreasing the chances of front-end changes break the tests.

5. Don't do this: var el = cy.get('selector')

Remember. Cypress is not Selenium! 😅

Cypress has its own architecture, where although in many cases it allows writing code that seems synchronous, even if it is asynchronous (since it puts each command in a queue for later execution), it is not possible to do something like:

const myBtn = cy.contains('button', 'My button')
myBtn.click()

However, you can do:

cy.contains('button', 'My button').as('myBtn')
cy.get('@myBtn').click()

Most of Cypress's commands are chainable!

6. Do not test external applications

Relying on Google's GUI login for your tests or some third-party API can make your tests unstable, as changes to these services (which you don't control) will break your tests, even if it's all right "on your side."

To ensure that such services are in line with your application, you can have a smoke-test suite, for example, or contract tests.

7. Tests too small or too large

End-to-end tests are not unit tests. Due to the cost of running them, it's worth adding more than one assertion per test to save time.

However, beware of extensive tests. Maybe these are testing a lot of unrelated things and could be broken down into smaller ones.

8. Do not use the after and afterEach hooks

If something goes wrong during the execution of the tests, such hooks run the risk of not being executed, leaving "junk" in the application.

As a good practice, do any cleanup before running the tests, using the beforeEach hook, for example.

9. Do not use cy.wait(Number)

Cypress already has automatic waiting with different default timeouts to wait for elements to be visible, for animations to end, for requests to be sent and responded and for pages to be loaded.

What you can do to make your tests even more robust is wait for elements to be visible:

E.g.: cy.get('[data-cy="avatar"]').should('be.visible')

Or, you can wait for a particular request that you gave an alias to finish.

E.g.:

cy.intercept(...).as('myReq')

...

cy.wait('@myReq')

I wrote about it on cy.request vs. cy.intercept.

10. start-server-and-test

Use mechanisms such as the start-server-and-test library to initialize the application server before running the tests, ensuring that it will run with the correct code and that the tests will only run when the application is responding.

Besides, such an approach will help you run your tests on a Continuous Integration server.

11. Set the baseUrl

By setting the baseUrl in the configuration file (cypress.json), your tests can visit pages via relative URLs, making them cleaner.

In addition, the baseUrl can be overwritten via a cypress.env.json file, environment variables (CYPRESS_*), command line, plugins, etc., making it possible to run the same tests against different environments.

Conclusion

By following these best practices, you will have fast and robust tests that your team trusts and helps to maintain and evolve.

Forem: Walmyr

Building and Testing a Language Detector App

Introduction

Understanding the Language Detector App

How It Works

Testing the Language Detector App with Cypress

How the Tests Work

Running the Tests

Conclusion

Radical Simplicity

Radical simplicity in the context of Cypress web test automation

Conclusion

Test Design: What Everyone Should Know About Test Automation

How solid test design turns automation into a trustworthy quality signal

1. Suite, Sub-suite, and Test Cases’ Descriptions

2. Test Levels

3. Abstractions

4. Assertions

5. Independence

6. Infrastructure and Environments

7. Tools

8. Accessibility

9. Testability

10. Security

11. Tests' Size

12. Conventions

13. The 3A Pattern (Arrange, Act, Assert)

14. Performance Optimizations

15. Test Stability and Reliability

Solving Complex Test Automation Challenges with Simplicity

Logging into different environments with Cypress

Learn how to log into different environments with Cypress, protecting sensitive data, such as username and password

Simulating Internet Outage and Recovery using Cypress

Unveiling Cypress's Power: Testing Internet Outages and Recoveries with Precision

The Test Scenario

Breaking It Down

1. Simulating Network Error

2. Triggering the Request

3. Handling the Network Error

4. Triggering Recovery

5. Simulating Successful Request

6. Validating Result

Conclusion

Filtering the available browsers in Cypress

Learn how to define which browsers will be available to run tests with Cypress

Making only web browsers available to Cypress

Testing copy to clipboard with Cypress

Learn how to read information saved in the browser window, such as what is held in the clipboard

cy.get() vs. cy.contains()

Get to know one of the differences between the commands cy.get and cy.contains

How to login programmatically with Cypress

Learn how to make your automated tests faster by authenticating via API

Bonus - Custom Command

The importance of testability for web testing automation

Learn how to improve the readability of automated tests written with the Cypress framework

How to create fixtures with random data using Cypress and faker

Random fixtures? Yes, it is possible!

Best practices in test automation with Cypress

Get to know one of the differences between the commands `cy.get` and `cy.contains`