Up And Running with Pest
Playing
24. Accepting friend requests

Episodes

0%
Your progress
  • Total: 4h 19m
  • Played: 0m
  • Remaining: 4h 19m
Join or sign in to track your progress

Transcript

00:00
Okay, so let's take a look at accepting friend requests. Just before we do that, we didn't write a test in the last episode
00:07
that covered whether we can duplicate adding a friend request. Now, we already knew to use sync without detaching, so this didn't add additional records. But let's go ahead and just cover this with a test.
00:17
So we want to make sure that if I choose to add a friend twice or add someone by their email address twice, that it doesn't duplicate that friend request because that just doesn't make sense.
00:27
So let's say does not create duplicate friend request. And we've already got the functionality here, so really what we need to do is just have two people and we need to add this friend twice.
00:43
So we're going to go ahead and say user add friend and we're going to add that friend and then we're going to do that twice. So we can just copy this line down.
00:54
Now, what we want to do is expect that the count of the pending friends doesn't equal two or only equals one. There's a couple of ways around this we can do, but we're going to demonstrate a chain of methods
01:08
that we can use to make this a little bit clearer. So what we would normally do is say expect and we would say user pending friends of mine and we would say to be or to have count one.
01:26
So we're saying that we expect this just to be one. Let's go ahead and run that test and sure enough we get green. So there's actually another way that we can write this test really just depending on how you want this to read.
01:37
We do want to expect that it only has one, but what we can actually do is say not to be two, for example. Maybe that's a little bit clearer because we're doing this twice, so we're expecting it not to be two.
01:52
It's going to work in exactly the same way and still pass or we could say expect to have count two, not to have count two. So this is the kind of expressive syntax you'd expect from PEST. It reads really, really nicely.
02:10
So it's really up to you what you do. I'll leave it like this because I think this is a little bit better, but that just goes to show us how we can negate what we're doing here that we previously just used on its own.
02:21
Okay, so now that we've got that out of the way and looked at that interesting piece of PEST functionality, we're going to go ahead and write a test here to see that it can accept friends.
02:30
So let's go ahead and just map this out how we would want it to actually look in our controllers. Remember, we've not done anything with our controllers just yet and then we will go and fill in the functionality.
02:40
So we're going to go ahead and say user add friend. So I am adding this other user. Now this user needs to accept my friend request. So let's say accept friend and let's pass myself back into that.
02:54
So this is basically just an exchange between two people. So what are our expectations going to be? So let's say expect user and we've got pending friends of mine. Why don't we also implement accepted friends of mine
03:12
and we're going to go and say that we want to expect the count here or to have count to be one. That makes sense. Now if we run this at the moment, of course, it's not going to work.
03:23
Let's go over and sure enough, we don't have an accept friend method. So let's go ahead and implement this accept friend method to get this to work and then we're going to add another assertion to this just to properly cover it. Okay, so let's go ahead and say accept friend
03:43
and let's, of course, accept in here a friend. Now we're going to do this kind of in reverse. We're not going to say that we want to update our friends. We're going to say from that friend,
03:57
we're going to go ahead and grab their friends of mine relationship and we're going to update the existing pivot on that way to ourselves. So that just does it in the reverse order, but it works a little bit better this way and let's go ahead and say accepted to true.
04:16
Now we'll go ahead and break this test in a minute just to see how doing it the other way doesn't quite work. Let's just run that test again and just see what we get. Okay, so assert count must have count or must be iterable.
04:27
So of course, over in our friend test, we don't have an accepted friend relationship. So let's go down to our pending friends of mine and let's create an accepted friends of mine. And you can see now why we broke this out into another method
04:45
because we can just reuse the friends of mine relationship, but set the condition of this to true for accepted. Let's go ahead and run our test and see what we get. There we go. It works.
04:55
Now let's just fiddle around with this and just see because if we said user, for example, or this friends of mine and we updated this for the friend ID, let's go ahead and run this test.
05:06
And you can see it actually fails because technically it's the friends relationship that we need to update to have this work nicely. So let's go ahead and switch it back.
05:15
We've got a test now to cover that. So we know that even if we wrote it the other way, it would still work. Okay, so let's look at what else we need to do. And if we go back to our test,
05:28
let's see what else would strengthen this expectation. Well, it might make sense to grab a list, to pluck out a list of the friends that we have in accepted friends and check that the user's ID is in there or the friend's ID is in there.
05:44
So what we could do is write another expectation here and say user accepted friends of mine. And we could maybe go ahead and pluck out the ID of the friends and see if it contains.
05:58
So let's look at another pest method here to contain friend ID. So we want to make sure that our friends contain that friend that we actually added. We could have technically done this for the other tests. I've added this in here purely so we can learn
06:17
about refactoring pests test a little bit later to make them read a little bit nicer. And we're going to get to that in a later episode. So let's just go ahead and run this test.
06:28
Sure enough, we get green. That works. And we're going to come back to this a little bit later on in the course and refactor it to make it look a little bit nicer.
06:36
Okay, there we go. We have added the ability now to accept a friend request. We've written up a couple of expectations here that we can refactor later. Let's move on to the next episode where we're going to get a list of all of our friends.

Episode summary

In this episode, we first tie up a loose end from last time by making sure users can't add the same friend twice—we write a test case so that duplicate friend requests aren't created. Using PEST, we see a couple of different ways to write the assertion and learn how to use negation to make things even clearer.

Once that's sorted, we dive into the heart of the episode: implementing the ability to accept friend requests! We sketch out how the test for accepting a friend request should look, then fill in the actual functionality in the code. This involves writing an acceptFriend method and setting up a new "accepted friends" relationship so we can check both pending and accepted friends separately.

As we go, we explore writing more robust assertions, like checking that the correct IDs show up in the list of accepted friends. Plus, there's some discussion about how we'll be able to refactor the tests later to make them even nicer to read. By the end of this episode, we've fully covered accepting friend requests and have solid tests around it. Next up—listing all your friends!

Episode discussion

No comments, yet. Be the first!