Instead of grabbing the hexId variable or the first Todo item, we want to grab the hexId variable for the second Todo item, and then the next thing we need to do is update the data we're sending. We don't want to set completed equal to true; we already did that manually up above. This one we're trying to set to false. We are also going to update the text so we can leave that in place. I'm going to go ahead and tweak the text value a little bit, adding a couple of exclamation marks on the end. Next up, the assertions. We're still expecting a 200 to be the status code that comes back. That part's great, and we are still expecting the text to equal text. For completed, though, we're expecting that to be false and we're not expecting completedAt to be a number; it was a number originally but after this update it should have been cleared since the Todo is no longer completed. We can use toNotExist to assert that completedAt doesn't exist:
it('should clear completedAt when todo is not completed', (done) => {
var hexId = todos[1]._id.toHexString();
var text = 'This should be the new text!!';
request(app)
.patch(`/todos/${hexId}`)
.send({
completed: false,
text
})
.expect(200)
.expect((res) => {
expect(res.body.todo.text).toBe(text);
expect(res.body.todo.completed).toBe(false);
expect(res.body.todo.completedAt).toNotExist();
})
.end(done);
});
With this in place, our test case is done. We can now delete those comments, save the file, and rerun things from the Terminal. I'm going to rerun the test suite:
We get both of our PATCH tests passing. Now, as you've probably noticed, for patch we didn't write those test cases for invalid ObjectIDs or ObjectIDs not found; you could add those but we've done them so many times so far, I don't see that as a necessary exercise. These two test cases, though, they do validate that our patch method is working as expected, especially when it comes to the slightly more complex logic that patch requires to get everything done. With this in place though, we are done testing our last route.
We can go ahead and make a commit and move on to the final section of the chapter. Over in the Terminal I'm going to run git status. We'll see we have one modified file, server.test file, which looks great. We can use git commit with the -am flag to make the commit, Add tests for PATCH /todos/:id:
git commit -am 'Add tests for PATCH /todos/:id'
I'm going to go ahead and make that commit, then I'll take a moment to push it up to GitHub and with that in place we are done. In the next section, which is the last one for the chapter, you will learn how to use a separate test database locally, so you're not always wiping your data in the development database as you run your tests.