 Resources from Filip Hric in 2024

Approaching testing at a component level has definitely its benefits. Seeing your component rendered in isolation, and making sure it behaves correctly with different properties is definitely faster that trying to interact with an app at end-to-end level. On the other hand, seeing your app render in a browser in an end-to-end test is a significant advantage. 

With Cypress’ component testing you can now take the best of both worlds. Render component and interact with it in a real browser. You can pass different properties, spy on its function calls, click and type into them or even intercept its network calls. All this with a minimal setup and vast options.



## What you'll learn
- setup component testing in Cypress
- customize component mounting properties
- render a component in a browser
- examine a component with different passed properties
- make asserrtions on component’s emitted events
- render a component with content passed into its `<slot />`
- catch edge cases by calling actions and passing values into Pinia’s state
- handle router and it’s effect component behavior

Vue (pronounced /vjuː/, like view) is a progressive framework for building user interfaces. Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is very easy to pick up and integrate with other libraries or existing projects. On the other hand, Vue is also perfectly capable of powering sophisticated Single-Page Applications when used in combination with modern tooling and supporting libraries.

Write, Test and Debug Vue 3 Components in the Browser Using Cypress

Your app can react in various way on different network conditions. Cypress has a great toolset for setting up those conditions, which enable you to test your app thoroughly. That way you can ship your app with confidence.

Cypress’ .intercept() command is one of the most fun command to use. And it’s also one of the most useful.

Especially when you are done with all your happy paths and want to increase your test coverage with some edge cases.

These edge cases can mean different data, headers or server behavior. You can modify all of these, dynamically or with a static fixture prepared beforehand

Fast, easy and reliable testing for anything that runs in a browser.

cypress

Test Network Edge Cases with cy.intercept() Command in Cypress

You can simulate a network condition, where an http request does not make it to server. When that happens, you want to make sure the app is showing the user a correct message. By passing `forceNetworkError` attribute, you’ll be able to simulate such network conditions and see how application behaves under given circumstances.

Simulate a Network Error Using .intercept() Command

Server may respond differently when providing a response to a logged in user. Usually, a user is identified when an authorization header is sent with the request. With .intercept(), we can dynamically add a header to a request and skip the login process. Server will provide the same response as it would when a user would go through login process.

Send Network Requests with Authorization Headers in an Intercepted Request with Cypress

When user waits too long, we might want to give them an option to reload page and try again. This is usually a hard case to reach and test effectively. But the .intercept() command provides us with a `throttleKbps` option that can limit the bandwidth, or we can use `delay` option that will delay our response for a given time.

Test Slow Network Conditions in Cypress by Throttling and Delaying Intercepted Requests

Servers sometimes use entity tags that identify a user and provide them with a cached response if needed. This can create ambiguity in your tests. To make your tests more stable, you can modify the request headers that take care of this caching. By deleting `if-none-match` header with `.intercept()` command, you will get a fresh response from server every time.

Prevent Response Caching in Cypress by Deleting 'if-none-match' Request Header

When a static response is not enough, we can take the real data from server and modify it to our liking. This saves a ton of time, because we don’t need to create the data ourselves. Instead, we can take e.g. response body and change only a desired attribute. This gives us one more advantage, because we can first make assertions on real data, and only then make changes. This is a great advantage compared to providing a static response, that essentially creates a blind spot for any API changes.

Dynamically Combine Real and Mocked Response Body Data in Cypress

When you don’t want to stub your response or create your data before the test, you can change the request your application makes altogether. If your server recognizes different queries, you can modify your request‘s URL and add a query that will specify what kind of data you want to get.

Dynamically Add Queries in Cypress Intercept Function Requests

When testing certain user stories, you may want to start with a clean state, but then return to the initial page and see the data you have created. This can be problematic if you are stubbing your requests. Luckily, you can limit how many times you a request should be intercepted.

Configure cy.intercept to Only Intercept a Network Request Once 

Instead of explicitly providing the exact body, you can choose to save the data you want to use in a separate file. When you create a file in the fixtures folder, you can reference it using `fixture` option in the .intercept() command. This will automatically look into the fixtures folder and load the data from the file.

Use a Fixture in Cypress to Provide Response Data to Network Requests

With .intercept() command, we can change the response body. This enables us to provide our own response instead of the real one coming from server. We can then test our application’s behavior under different situations and test different edge cases.

Change a Response Body with cy.intercept to Provide Your Own Data in an API Call

Frontend application can react differently to various server responses. One way to test the application behavior is to change response status code. .intercept() command in Cypress has the ability to stub the status code and error message that the server would provide on error.

Stub an API Request Status Code and Error Message with cy.intercept

Importing styles is going to be essential for all of our components to render properly. We will do this similarly as we do in our application - at top level. `component.ts` file is the proper file for this, as this is the one that gets loaded before running our specs. Importing our `index.css` file here will make all of our components render with the correct styles.

Setup Global CSS Properties for Cypress Component Tests

Some components can have properties passed into them, For these, we can use an options parameter in our `cy.mount()` function and pass `props` attribute which will define the properties we want to pass into our component. This way we can test whether different properties correctly render out in our component.

Pass Properties Into a Vue 3 Component Within a Cypress Test

To create our first test, you’ll create a spec file that pairs with the component. Usual naming convention is using `filename.cy.ts` (or .js), but this can be easily set up in `cypres.config.ts` file. After you create the spec file, you can mount the component by importing it and using cy.mount() command inside an `it()` block. This will render the component inside Cypress app, but will not load all the dependencies that the component needs, like css styles. These need to be imported into the spec file manually. Since we are running our component in a browser and inside a Cypress app, we can interact with it using common Cypress commands.

Mount and Test a Vue 3 Component in Cypress

To start with component testing in Cypress you need to open Cypress and go through setup wizard that will help you out with your first steps. It will take you through a couple of steps, where you’ll install dependencies and create important configuration. Most of this is done for you, but you can customize anything. In our application, we will be working with Vue 3 framework with Vite bundler.

Setup Vue 3 Component Testing in Cypress

`emit()` function enables components to communicate with one another. While this communication is a good candidate for end to end test, we can also test this in isolation within component. To do this, we’ll use `cy.spy()` function that will watch for the defined function call. Using this, we can confirm that our emitted event was actually invoked.

Use Cypress cy.spy() Function to Test a Vue 3 Component’s Emitted Events

By passing a `slots` option to our `cy.mount()` function, we can define content to be rendered inside our current component. We can use default or named components and eve use Vue’s `h()` function to create element and pass components with desired properties.

Render a Vue 3 Component with <slot /> and Test its Content Properties

Some components render differently based on the route they are rendered on. To use router within component tests, it is best to define its default values in `cy.mount()` function. Since we can customize this in any way we’d like, we can create a custom `path` attribute where we can pass our own routes and test our component behavior against them.

Test a Component Rendering Within Different Router Locations in Cypress Component Test

Every component test that uses Pinia needs to have Pinia imported and initialized. Instead of doing this separately for each test you can customize your `cy.mount()` command to automatically use a default store. You can further then customize it to use your own store in case you want to change its state.

Rewrite Cypress mount() Command to Provide a Default Store to all Components

Instead of calling an action function to change the state, we can choose to change it directly by importing the attributes from our store. In order to not loose reactivity while destructuring properties we can use `storeToRefs()` function.

Topics

Instructors

Content Type

Filip Hric