Assert on Database Snapshots in Cypress
The lifecycle of our application doesn't end when we fire off an XHR request to the backend. We also want to assert that our data makes it into our database, to test our contract end-to-end. In this less, we'll make assertions on our database state, to ensure our contract is exercised completely.
Instructor: [0:00] One of the layers of this stack that we still haven't seen how to assert against is the database. We've seen how to test against the UI, how to assert on the front-end stores, but it's important for us to test against all layers of the stack. To illustrate why, let's see an example.
[0:16] Let's say that we go ahead and create a new todo. We've seen this code before. What I'm suggesting we want to do is that before this, we want to say that the database is empty. Afterwards, we want to assert that the database contains one todo, and that todo contains third todo as the text.
[0:35] Why is it not enough simply for us to assert that the todo shows up on the UI? Well, let's go ahead and paste in that assertion. We'll reopen Cypress and see that the assertion passes, even though we haven't yet gotten the response back from the back end. The reason for that is because I've inserted an artificial delay in the server process to further illustrate this point.
[1:00] The point is that we commonly show the content as created on the UI while the network request is still in flight. We do that so that the UI doesn't feel sluggish, but anything could happen. The network could time out. Maybe the request is malformed. Maybe even the API says that the todo was created and it hasn't actually been inserted into the database.
[1:26] The point is that our assertion here can give us a false sense of security, even though we haven't tested the entire contract. It's part of our contract for the data to be in the database, to be persisted, or else we're going to have a fundamentally broken experience.
[1:44] Let's go ahead and make it possible to assert on our database. We've seen how to write Cypress code in the past that interacts with our back end. We write a cy.task. We can call it db.snapshot. Specifically, we're going to look for the todos on the snapshot.
[2:02] We can say that it should be empty at first. Then what we want to do after we know that we've created it is say that it should deep equal. We'll pass in the array and just use these keys that we created, so third todo and completed is false.
[2:28] Let's go ahead and pop into our plugins file again. We will add a db.snapshot method. This takes the name of the table that we want to get, which in our case was todos, so overturn db.snapshot, passing in the table, remembering that db is the library that we created to seed our database.
[2:51] Let's go ahead and open that up again and add a snapshot method. In here, we just add snapshot. This takes the name of the table that we want to pass the snapshot of, remembering that all of this code is fairly specific to our specific database.
[3:08] You have MySQL, Postgres, RDS, whatever you have. Just use your own version of this code. This is how to do the integration so it'll just return db.get, passing in the table name, because that's how we do it in lowdb. We'll head back to our test.
[3:24] Let's go run it in Cypress. Here, we can see the task that ran. This is the snapshot. We can actually see the database snapshot with that one todo. Then we can see the assertion that ran on that object.
[3:41] Great. Now we have a lightweight way to test a new layer of the stack. In the next lesson, we'll keep expanding upon this by testing our XHR requests.