Starting with component testing

I didn’t understand the "why" of component testing when it was first released in alpha version back in version 4.5.0 but it seemed like a big deal to many folks around me. How is it different from e2e testing? Do I even need it? What’s the fuss about? But I decided to dive in and the more I played with it, the more I got the appeal. I’d like to share that with you.

​
Let’s start with the basics and answer the main question.

​

What is a component?

I choose to look at them as lego blocks. In web development, these lego blocks are what a web application is built of. Lego bricks come in different shapes and sizes and can serve different purposes. Some lego block are used just once, some are reused all the time. Same goes for components!

​

​

Each component has certain visual and functional properties. Like a lego block, a component can be a common one, that get’s used all the time and changed just slightly. Or it can be a unique one, that serves a specific function.

​
Let‘s take a look at a simple Vue component:

<template>
  <button class=".green-button"></button>
</template>

<script setup lang="ts">
defineProps({
  buttontext: {
    type: String
  }
});
</script>

​

In my application, I can import the component anywhere I need it, and use it like this:

<MyButton buttontext="Hello world" />

​

The button will render differently based on what property is passed into it.

​

Why test a component?

If you need to make sure that this button looks good with an emoji, special character or a normal text, what do you do? Going with e2e approach - clicking through our app to get to it is not going to be effective.

​
Enter component testing.

​
Testing a component in isolation gives you a much wider set of options. Imagine you want to refactor your component. While you are doing so, you can get an immediate feedback on anything that might be broken. In other words, it’s easier to just render a component with an emoji, than go through your app looking for it.

​

This is why component testing is growing in popularity and tools like Jest, Storybook and now Cypress are widely used.

​

Buttons don’t seem like much though...

You are right. This example is way too simple to show the value of component testing.

​

Instead of a button, imagine a login form that validates a multitude of different inputs. How do you test that the form throws correct errors?

​

Or imagine a complex online calculator that converts and calculates a result based on different data. How would you test all of the nasty edge cases?

​

Or imagine your own application that just takes ages to test, because you need to make sure every possible input works as intended. Lot of work, huh?

​

Testing a component in isolation can provide a lot of value, especially in cases like these.

​

What sets Cypress apart

The main difference between Cypress and other tools is that it runs its component tests in a real browser. Besides that, you have all the power of Cypress API at hand for your component tests as well. You can click and type, make assertions or intercept network calls. You can spy on functions or stub them.

​

There’s not a place in your app that’s not reachable in your app!

​

In upcoming weeks, we’ll be taking a look into how to set up component testing and test a real application. I’m excited to take you on this journey with me. The great news about this is that along with this newsletter course, I will be releasing my egghead.io course on the topic on component testing, which I highly recommend you to check out!

​

See you in the next issue, where we’ll talk about how to set up component testing in Cypress
​

​