Assert on Your Redux Store with Cypress
Cypress doesn't provide out-of-the-box ability to make assertions on our frontend stores, so let's expose the store to the tests, and assert on it. We'll use our knowledge of Cypress's asynchronous programming style to access properties and functions on the store using cy.its and cy.invoke.
Recommended Homework:
- Consider why it's valuable to test against your frontend store when you can test against the UI
Instructor: [00:00] Right now we're not able to make assertions at all levels of the stack. We'd really like to be able to. When breakdowns happen, we want to know why they happened and where they happened. Is something not painted on the UI because of a UI issue? Is it because of the underlying representation in the redux store? Right now we don't know.
[00:21] We can't make any assertions on our front-end stores of any kind. Let's go ahead and make that possible. We'll start by opening SRC/index which is where in our application we've defined the store. We'll say, "If window.Cypress," which means we're in a Cypress testing environment. Then we know we're safe to expose the store on the window.
[00:43] Cypress exposes the window as cy.window which will help us access it. Remember that Cypress code is asynchronous. We don't just have access to window here. Let's take a call back and console.log window.store just to make sure we've set everything up properly. It looks like we have. Cypress exposes a way to access these properties by using its. We can say, "Its store."
[01:14] What we want is to be able to make assertions against the state of the store. In order to get the state of the store, we would normally call, "Get state," which is a function, not a property like store. In order to do this, we can call, "Invoke."
[01:29] We can call, "Invoke. Get state." Now we should have our state. Let's take a look. We'll console.log state. Great, this looks like the state we expect because this is before we've waited for any pre-load.
[01:49] Instead, let's make an assertion on the store. We can say it should deep equal to-dos, which will have the state of the to-dos array and visibility filter, which will be, "Show all." We want to assert that the to-dos have loaded.
[02:11] Let's go ahead and paste in the to-dos that we expect to be there and save it out. Let's revisit Cypress and see what happens. In fact, this test still passes because Cypress waits for the to-dos to load just like Cypress will wait until the specified time-out for UI elements to load.
[02:31] It will also wait until the specified time-out for our stores state to match what we expect. This makes it really easy to wait for an assert on asynchronous behavior.
Hi Brett! Thank you for the course! I'm loving it so far!
I have a question: would you consider checking Redux state in this manner a good practice for real projects? You mentioned in a previous lecture (and I've read elsewhere) that testing implementation details can create brittle tests and it seems like this might fall into that category?
I totally understand that this lecture is probably aimed at showing off the capabilities of Cypress rather than suggesting this as a good practice. I'm just curious to hear your thoughts!