Welcome back, in this lesson we'll fire up our development VM, we'll run our test suite, and then we'll fix any code errors that might occur. So the first thing we want to do is head to our terminal. Let's make sure we're in the right directory. Okay, so see here the Vagrant file, this is the important part.

We're going to make a call to the Vagrant binary Vagrant up. What this is going to do is go through that Vagrant file, it's going to create a virtual machine based on our settings here. So we're going to use Ubuntu xenial 64, we're going to do some port mappings, we're going to map a app files directory to this current folder and it's going to then provision it with Python 3.

6 so that we have all of what we need installed and ready to go. So running this is going to take a while. It's got a lot to do if this is the first time your running it it's going to download that virtual machine. I've already run that so it's going to be a little bit faster, but it still has a lot to do in booting it up and configuring it.

If you're familiar with using Vagrant feel free to fast forward. I'm going to speed up this next part from a four minute process down to about 15 seconds. That way you can at least see the output so that you know for yourself what's normal and what's not. Okay, and now it's done. So let's check this out and make sure that everything is configured correctly by logging in, so you can do that with Vagrant SSH.

Great, so we're logged in and let's change directories to /app_files and if you list this off you can see that it has everything that it should, because it's mapping all of this to our app files directory. So now we can access our code inside the VM. So let's run our test suite and make sure that everything is okay before we edit any code and we can do that by running bash test runner.

Okay this is a perfect example of why tests are invaluable. If you were to trust this code as it came from GitHub you would be confused when you deployed this and it didn't work, because you'd assume that the code was correct. So let's figure out what's going on. We have an error and we have a failure.

Let's start with the error. This is in the test get handler one. So this is the functionality for getting one record and it says that list items must be integers or slices not strings. So what's happening, if we look in our test, and it's in line 92 This body is actually a list. Now the only condition that would force that to be a list is if we got all of the records and not one.

Let's look at get all or get one. So our to do ID is not coming through. We set it to none up here. Notice the problem? We're not setting it here, so let's grab that. We're going to set that, let's save it, now also notice event query string parameters ID. So copy this, if we go back to our test, scroll up, notice that it's not even the correct event.

So what we need to do is change this as well. So this is my crude attempt at showing you why it's so valuable to use tests, because you can't assume that the code you wrote or somebody else wrote is going to be correct. So let's save that, let's jump back here, let's clear the screen and run our test again.

Now if all went well we'll have an error or a failure rather and our error will be gone. So there it is. We still have a failure, that's expected. That's in our delete, so let's go to line 54 of our test delete. We're asserting that this here is deleted. Let's take a look. Our event looks good. Let's go into our delete, notice the same thing, okay.

So again, this is my crude attempt to help solidify the value of tests. Let's close these out and head back to our test and now this should all work. Okay, so again, trying to solidify the value of testing. This has helped us catch a couple of issues that made it to get maybe the developers don't test their code or don't run their test suite before they push.

So it's valuable to always make sure that before you do anything with that code that you run the test suite to give yourself a before and after. If you run the test suite like we just did and it comes up all fine, no problem, but if it shows something is broken if it's not your code you get to push it back on to the other developer to get them to fix whatever they broke or if it is your code like we just did you have to fix it.

Okay, now that all of our code is working we know that it's in a good state that it can actually be deployed. So in the next lesson we're going to take a look at how to get the API Gateway and Lambda functionality deployed so that we'll be able to modify our front-end in the subsequent lessons and get that all deployed and tested.

So if you're ready to learn a little bit more about API Gateway, Lambda, and SAM Local then I'll see you in the next lesson.