Changing your API and target via your requests

- [Instructor] As we build and test our API, read access is great and will let us do quite a few things, but the real value, the real importance, is making sure we can write to the API and modify the items we expect. Now, this is where things get a little scary. If you're working with a payments API, you must be careful not to unexpectedly charge someone or change account balances. If you're working with an API that sends text messages or emails, you don't want to accidentally spam someone. So testing write access requires us to be thoughtful and deliberate about how and where we test. Unless your API has a sandbox mode which won't create side effects, stay away from payment processing, emails, texts or anything else sensitive. For this test, we're going to do the simplest thing possible with zero risk. We're going to start the private repository that we had from our last video. When you run this test, if you get an error that says, resource non-accessible by personal access token, go back to the first lesson of this chapter to get your access token permission set correctly. And remember, let's be careful. Now let's go to our editor and see the test we're actually going to implement. In this case, the test is pretty simple. Say given, I'm an authenticated user, when I star my is your API misbehaving repository, then my is your API misbehaving repository will list me as a stargazer. Immediately, we should see that our given line is the same as last time around. So we only have two functions to implement, the starring and then validating it. So let's move to command line and get this started. And once again, we run the command we've run many times at this point. Vendor bin behat. And if all's going well and we haven't broken anything, which happens occasionally, we should go ahead and see all of our test pass and a couple of ours aren't implemented yet. And sure enough there's two functions that we need to implement. So we copy and paste these and head back to our editor. In our editor, it really doesn't matter where we put these. We'll put them at the bottom just before our monkey test. But don't worry, we're going to clean this up later. Now we need to go ahead and implement this function just as we have before. So let's do GitHub user equals, we'll say this, we'll use the client that we've been using all along. We'll use the API under the current user context, and we'll get the information of that user. So we'll show the login. So this will give us back the actual user who's logged in which should be us. Then we go ahead and we use the client again, use the API, the current context. We'll now use the starring interface to star our GitHub user's repository and that particular repository. Now we want to make sure that this repository lists us as a stargazer. So we'll use the same GitHub user command that we had before. So just copy and paste this line of code. So now we need to go ahead and build out the actual repository we're looking for. We'll say our repo is the GitHub user, and we'll concatenate this string to make sure that we're looking for the right endpoint here. Arg1. We'll get our list of stargazers from that repository. So again, we'll hit the API itself. So do a client. We'll hit the repo endpoint. We'll get the list of Stargazers, and we'll get all of them for GitHub user on this particular repository. Let's scroll down a little bit so we move this all in space. So then we'll iterate over these and we'll go through each stargazer. We'll say, if our GitHub user equals the Stargazers, login. We'll return true. Now, if we don't have a match in any of that collection, we'll go ahead and throw our new exception 'cause we have a problem that we need to address. So we expected GitHub user to be a stargazer, and we'll go ahead and make sure we're specific about what repository we're looking at. All right, so that was a lot of work. If you're feeling like that was a lot of typing, a lot of analysis, or a lot of explanation, it absolutely was. But don't worry, one of our later lessons is about refactoring it and cleaning this up to make sure it's a lot simpler. So with that, let's go back to the command line and run this and see how it works. And once again, if all's going well, our tests should pass, and sure enough they do. Now this is a little bit different one. Notice, we've starred, we haven't unstarred it. So if we go back to GitHub, we should see ourselves on the stargazer list. So let's do that now. We have one repository, so it should be pretty easy to find in my case. And look, somebody has starred, in fact, I've starred it. Alright, so we've proven we've accomplished something huge. We've modified something via our API test and it worked. Generally, I'd say stop and take a break to celebrate, but we have a different problem. What happens the next time we run this test? Or to put it more specifically, now we have a test that changed the state of our data, changed the state of our system, but we never cleaned up afterwards. Therefore, the next time we run this test, we've already starred it. So then I star at step doesn't actually do anything. Therefore, it worked and it didn't work, may look exactly the same, that's a problem. So let's create a new test and clean up after ourselves.