When component uses a state management tool like Pinia, it needs to be defined within the test. To use Pinia inside the Cypress component test, we need to create a Pinia instance and pass it into our store. For changing the state we can call our actions directly from within our test and assert different attributes of the component with Cypress commands
Instructor: [0:00] I have a very simple notification component. In the template part, you can see a main div element that will show based on whether the notification show attribute is set to 1 or to false. Inside this div element, we have three more elements. [0:21] These first two are icons. Depending on whether we get an error, we show an error icon or info icon. You can find these two over here in the script part of our component. Then finally, we have our notification message which will render out the message of the component.
[0:41] All of this is handled by our store, which can be found in store.ts file, and that contains all of the attributes of the default state, as well as actions that change these attributes. Over here, we got a couple of actions. One of them is handling the parameters of a notification attribute.
[1:04] When we take a look inside, we'll see that there's a function that'll take two parameters. The first one is the message. It will change to notification message. Then, the second one is the parameter called isError. This will be set either to true or flase , based on whether we want to render an error image or an info image.
[1:27] Then, finally, we have a set time out function, which is responsible for automatically hiding our notification after four seconds. The state manager that we're using over here is called Pinia. Let's take a look into how we can handle this within our component test.
[1:48] I'm going to create a new file that will be called notification.cy.ts. As usual, I'm going to import the component into my spec file. I will create a test. I'm going to mount my component. Before I Run my test, I accidentally made a typo over here, so let's, of course, import to notification.view.
[2:22] I will save my test, and I'm going to Run it inside cyber app. The first thing we noticed is that we get an error that's coming right from our component. It says that get active pinia was called with no active pinia. What this is basically saying is that when we mounted our component that's relying on the pinia state, the component couldn't find it. What I'm going to do is to import my store and I'm going to call the use store function.
[3:03] When I announce it in my test, it's still not enough because while I'm using my store inside, my spec file, pinia instance needs to be created. In order to do that, I'm going to import create pinia function from our pinia package. Then I'm going to declare a constant called pinia and call the create pinia function.
[3:34] As a final step, I'm going to pass it into my use store function call and save my test. Now, we are getting no errors but we also don't see our component. The reason for this is that if we take a look into our store and its default state for notification, you'll see that the state is show set to false.
[3:57] If we were set it to true and save our component, we could see that the notification appears, although it has no text. If I add some text, it's going to render out, but this is obviously not what we want. Let me change it back.
[4:16] Instead, what we can do is to call one of the actions that change the state of our store so that would be the show notification action from before. Let me actually destructure it from our use store function. Since we are already calling that function over here, I'm going to move it down here and pass our pinia constant inside it.
[4:49] Since I'm already initializing the use store, I don't have to do that anymore. I'll just delete this line. Now, after I mount my component, I'm going to call, show notification and as I previously mentioned is going to take two arguments. First one being the message. Let's say something like this is an info message.
[5:17] Then the second argument is going to determine whether we are dealing with an error message or not. In this case, we pass false because we want to render an info message.
[5:30] When I now save my test, I can see my message appear and then disappear. The function show notification actually works as intended and changes our state. As a final step for this, we can write the test. To find my selectors, I can go to this, time travel time line, and find my selectors.
[5:54] Let's check for notification itself. Just going to paste the whole command into my test and make sure that the notification is visible. Also that it contains a certain message. I'm going to take this message into a constant. Let's do ghost message and then pass it both here and into our assertion.
[6:32] Let's also check the icon. Paste the command, should be visible. Then I'm going to take this first assertion. I'm going to flip it and make sure that the notification message will stop existing.
[6:59] In our show notification action, we can see that the timeout is set to four seconds, which is convenient because Cypress, by default, waits for four seconds with its automatic retry ability. When I now save my test, you'll see that everything is passing and when the message disappear and final assertion is going to pass as well.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!