Chapter 8. Testing and Debugging Your Application

In this chapter, we will cover the following topics:

• Generating test

• Using tests to think through your code TDT (Test Driven Thinking)

• Using VCR for API testing

• Getting your code onto GitHub

• Using Travis to run tests with every push

• Launching Gulp watch into your workflow

• Using Mockery to test your controllers

• Troubleshooting your application

Introduction

It's time for testing. For me, this does not mean TDD and testing every bit of code, but sometimes it is just a tool to help me think through some ideas, can quickly verify something is working as I hoped for. So, the recipes in this section will cover the concepts of what to test, how to get started, mocking, and more.

Generating tests

We need to make a test to start testing. And once again, Laravel makes this super easy.

Getting ready

SSH into Homestead using the command homestead ssh and cd into the recipe directory.

Note

I actually wrote this Artisan command for Laravel in September 2015. Inspired by all the easy workflows I get out of Artisan, I was surprised this one was not there. And I am not bringing this up just to show off, but just to show how you can add your ideas to this framework. Of course, some ideas get rejected, and this is fine, so go make a library to then use in Laravel, but keep trying! The commit is at https://github.com/laravel/framework/pull/10170.

How to do it...

1. Type the following:

   >php artisan make:test ResultsRepositoryTest
   

2. That's it!

How it works...

This is not much of a recipe! But let's dig into some of its aspects.

Why did I call it ResultsRepositoryTest? It might get tempting to just stick all your tests in one file but as your app grows, the file will become too hard to read...

Using tests to think through your code TDT (Test Driven Thinking)

In this section, we are just going to think about a small chunk of code using tests. It is not TDD in that I am testing Red, Green, and Refactor. It just uses unit tests to build, think, and iterate over simple or complex ideas. If you find yourself reloading a browser to see if something is working right, then it is a good sign. You can just be writing a test. Even if you end up not keeping the test, it will get you to the final code quicker.

Getting ready

SSH into Homestead using the command homestead ssh and cd into the recipe directory and let's get testing. Also, we are going to use the client that we made to query the Marvel Comics API. So, you will need an API Key and a Token from them at https://developer.marvel.com/account.

How to do it...

1. First, we need to add the key and secret to your .env file:

   

2. Then, we will make a test around this setup:

   >php artisan make:test MarvelApiClientTest
   

3. First, let's just write in the...

Getting your code onto GitHub

This next recipe will help you use this amazing tool called Git and a company called GitHub that has wrapped this technology with a service. Whether you are working alone or with others, it is important to work using version control systems, such as Git. You have automatic backup of your work by putting it on GitHub; you have version control so that you can go back in time if you need to find some old code; and you can easily work with others on your application.

Getting ready

Okay, so you will need a GitHub account, but the good news it is free, and it is a good place to show off the work you are doing. Once you have the account set up, make sure you have it installed on your PC/Mac; I will provide some links going forward.

How to do it...

1. Let's first make the new repo on GitHub:

   

2. Now, go to your command line on your Mac as follows:

   > cd ~/Code/recipes
   > git init
   > git remote add origin [e-mail]:alnutile/recipes.git
   > git add --all
   > git commit...

Using VCR for API testing

Alright, we are now making calls with Guzzle to a real API (see the section Using Tests to Think Through Your Code TDT (Test Driven Thinking) earlier in this chapter). But they are going to get pretty annoyed with us if we are hitting their API for all our tests. Also, it is going to slow down our tests. Right now, the speed difference is nominal since there is only one request, but once there are more, the time will really add up. So, to prevent this, we begin to use VCR to create fixtures of our HTTP requests and responses so that the next time we call them, they are delivered to us instead.

Getting ready

This one is a bit tricky on the installation. I will cover the installation in the upcoming steps, and then go into detail in the How it Works… section. Also, this is one of the recipes that I will be doing from inside Homestead, so begin with homestead ssh into your box.

How to do it...

1. Install SOAP for PHP:

   > sudo apt-get install php-soap
   

2. Then, we can go on...

Using Travis to run tests with every push

So, we have a test as seen in the first section of this chapter. And as we move on with our work, we want all of our tests to run before and after we push our code. Before pushing is easy; you run them, or as you will see later on, we set up Gulp to do that for us. But for now, we will get all the tests to run after we push to GitHub, thanks to Travis CI at https://travis-ci.org/:

So, in this section, we will set our App so that when we push to GitHub, we trigger a test on Travis. By the time we are done, we will have a badge on our repo showing the status of our project as well:

Getting ready

I will walk through the steps, but to begin with, sign into https://travis-ci.org/ using your GitHub account. So, first log in to GitHub, then when you visit Travis, you will see Sign in with GitHub on the top right.

The rest of the work I will take step by step.

How to do it...

1. First, we will make the .travis.xml file in the root of our application. For now, ours...

Launching Gulp watch into your workflow

As we saw previously, it is super handy to have Travis CI running tests as you push to GitHub. But it is actually pretty slow to wait so long to see whether your tests are passing; better to run it locally before you push. But who can remember to do this? Well, with Gulp, we will see no need to remember it, just run it!

Getting ready

SSH into Homestead using the command homestead ssh and cd into the recipe directory. Then, let's get going.

How to do it...

1. Take a moment to run npm install from within the app directory.

   Tip

   This will take a few minutes! Go get some coffee and welcome to NPM!

2. While this is running or after it is done, edit gulpfile.js, and make it look as follows:

   

3. Then, run gulp watch.

4. Start editing it:

   1. Edit MarvelApiClientTest.php, and add an example unit test:

      

      Simple test to show gulp working

   2. Then, you will see something like this at your command line:

      

   3. Then, go edit app/MarvelApi.php, and click on save. Go check out the console, and you will see...

Using mockery to test your controllers

We will cover a feature in Laravel to test your controllers. In doing so, I will show how to swap out the injected methods so that when your controller tries to inject the method, it will get your mock instead.

Getting ready

Since Mockery is already part of Laravel, we are ready to go! Just start gulp watch as we talked about earlier in this chapter if you want to tests to just happen as you write.

How to do it...

1. Make a Controller:

   >php artisan make:controller SearchComics 
   

2. Now, let's go set up the Controller called app/Http/Controllers/SearchComics.php for our request.

   When you are done, your Controller will look like this:

   

   Tip

   Note that @var MarvelApi is a nice feature in most IDEs. Even though it is an interface, I can tell it what concrete class it is representing, and then I can click into this class and explore it.

3. And our Route (notice we are taking over the home route /):

   

   Setting our search route

4. Make a test for the controller:

   > php artisan make...

Troubleshooting your application

In this tip, I am not going to suggest Xdebug or some browser plugin to watch all the methods being called. I am just going to cover some basic things you can do to approach any issue. I will cover a few common troubleshooting situations and how to deal with them.

Getting ready

Not much to do here; feel free to follow along by writing the code that will break, and then we have to fix it.

How to do it…

1. You go to a page in your browser only to see a breaking site:

   

   If I did not have debug=true in .env, then I would only see the Whoops message. Keep in mind you do not want to keep this as true on publically accessible sites, because it leaks out possible information about your application that can be a huge security risk. But locally it rocks.

   Also, unlike the preceding message where I just happen to have imported the wrong Response class, it should have been Illuminate\Support\Facades\Response. Sometimes, especially in Views, the message may not be so clear. So, here...