Building the supporting logic for your Feature Test is done step by step where you make sure every step adds something useful.
- [Instructor] Now it's time for the fun part. Let's fill in the logic to make our feature test pass. Our first step, is looking at an anonymous user. How do we test for that? In general, we could check to see if there's an active session, if there are tokens or credentials available, or we could make things even easier this time, and let's just say everyone passes. This isn't very good. We've got some option on how we can improve this. But let's save our efforts for the next steps. Now we need to make our request.
Luckily Guzzle is just a command away. So we can say, PHP composer, require Guzzle, HTTP, Guzzle, we'll say any version of six. And this will go ahead and resolve all the dependencies in the background. So we don't have to do anything else here. In this particular case, it's already installed, so we're ready to go. To make our first request, we go ahead and create a Guzzle client. Guzzle HTTP, client. This is one of the benefits of using an IDE, it will auto complete a lot of these things for you.
We'll go ahead and set this as, base_uri and we happen to know from the documentation, that this is api.github.com And now we need the response. So generally, we could start with something as easy as this. Response equals client, get, and we want to go ahead and fill in the actual request that we're going to make. Search/repositories, and then the query string we're looking for is behat.
Now technically, as is, unless this throws an exception, this is going to work. Unfortunately, the way behat works is this local variable, will not be passed along automatically. So we have to pass it along for ourselves. So in this case, we'll go ahead and add a protective property up here, that says protected property of response. We'll go ahead and set it equal to null. And then down here, we'll go ahead and wire that in. This response. So now after running iSearchForBehat, this property is available to us going forward.
Now let's address this last line here, of I get a result. This is very vague the way we wrote it. We're going to have to improve this at some point. But right now, lets just figure out something to make it pass. So, I get a result, can be defined a couple different ways. In this case, let's start the easy way. Response code equals, this response, will get status code. That is a built in function into Guzzle, that will go ahead and get the status code for us.
So say, is response code not equal to 200. If it's anything other than 200, we have a problem. So in that case, we'll throw an new exception. And we'll say, it didn't work. We expected a 200, response code, got a, and then we'll go ahead and fill this in because sometimes it's useful just knowing what we got even if it was wrong. So now when we run this.
This should pass as is. So there, we have a fully successful test. To test that this actually worked, we could break this URL. So let's add xx to the search here. Just so that we know it's a bad URL. And then when we run the exact same test again, we fail. Because we got a 404 Not Found. So we know that this did not work. Let's fix that before we go on. And let's look at one other way we could say we got a result.
So when we looked at the response code, we were looking at the request level. Let's look into the data itself. So in this case, we could look into the payload, by saying, data equals json_decode, let's look at the response. Let's get the body of the data itself. And this true value, in json_decode will make sure the data, is an associative array that we can manipulate as we want.
In the GitHub API, the data that comes back includes the top 50 results within this data set. But more importantly, it also includes another field called total count. So we go ahead and say, data, total count, equals zero. So if we get zero search results back, let's throw an exception. We found zero results. So now we know there was a problem. So now we run this exact same test again.
We should get green in every step, and we do. To prove that this works, let's go ahead and break our search. So add some random garbage to our search here. And run the exact same test again. And you can see, green, green, red. We found zero results. So this is a quick and easy way to prove our test are working as designed. Now at some point, we should still clean up I get a result, but now we have a couple different approaches on how to resolve it.
- The benefits of behavior testing
- Setting up a test environment
- Building your first API test
- Sending requests
- Validating response codes and payload
- Making authenticated requests
- Refactoring tests
- Writing to the API
- Establishing a system state for tests
- Using extensions
- Performing batch operations