The question you'll keep asking yourself when coding an application is,

does this thing actually work?

I mean, does it really work?

Unit tests help us answer that question by allowing us to test whether or

not the individual components of our application work.

Now, this is separate from whether or not two components talk nicely with each other

or whether or not the entire application works as a whole.

Those questions are the subjects of integration and end to end testing.

We'll be covering unit tests in this course with a brief peek at

integration testing.

Now in this course we'll be using mostly the spring test framework and

JUnit to test our app.

As the cherry on top we'll pull in some third party goodies to test our database

interactivity at the end.

But before we start looking at how to test controllers, services, and DAOs,

let's fire up the project we'll be writing.

The project is hosted here on GitHub as you see and is tagged for

the beginning of each video.

Check the teacher's notes for updating your local repo to match my code.

So that I can get a local copy of this repo on my machine,

I'm going to copy the SSH URL from right here.

And then I'll open a terminal window and change directories to the one where I want

to store this project, then clone the get repo into its own directory.

So I'll get clone and I'll paste that SSH URL here and

what this does is that it will download the whole project into a directory that's

named the same as the GitHub repo itself, spring-unit-test-weather.

So if I do a quick ls, I can see that that repo made it in to my directory here.

Excellent, okay, let me now hop over to IntelliJ to import the project.

So I'll just open this project since it was already configured as

an IntelliJ project.

And mine is under the Code directory.

Also under Screencasts and there it is right there.

I'll click OK and I'll go ahead and accept all the defaults here.

Click OK and let IntelliJ build that project and

soon the IDEA editor should fire up ready for

us to code Excellent.

There is our project.

I'll go ahead and add my version control route there.

Since this is a Gradle project, I'm going to open the Gradle tool window and

refresh dependencies, so I can get those pulled down.

Hit the refresh and you'll see these this output here at the bottom showing that

dependencies are downloading and looks like that finished fairly quickly.

Now before you run the boot run tasks you'll need to add API keys to

the api.properties file, that's api.properties right here.

Let me close this Gradle tool window.

This project uses the Google geocoding and places API to translate a search location,

like a city or zip code, into latitude and

longitude coordinates, as well as get coordinates for saved places.

The projects then use the forcast.io API to get live weather data.

So you'll need to sign up for API keys for each of those services and

I've put these instructions in the teacher's notes.

After you have your keys paste them here, here, and here.

Now I'm going to paste my own keys behind the scenes.

Okay, I paste my API keys into the API.properties file and I've closed that.

If you haven't guessed already, this is a weather app that will allow a user

to see live forecast and weather data for a searched location.

Let's run the boot run task and see this thing in action.

So I'll open the Gradle tool window.

And I'll go under Tasks > Application and double click Boot Run.

And I'll close my Gradle tool window.

And there we see our spring boot output.

All right.

Looks like the application has successfully started.

So let's go back to our browser, open a new tab and open localhost:8080.

Sweet.

And here's the app.

So we can search by zip code, I'll use mine, 60657.

And here we see up to date weather data for Chicago.

It shows the current temperature and this nifty little icon for

the current conditions.

No forecast data's on display yet, but you can definitely take this app and

make it your own.

Heck, you could even fork this project on GitHub and take it to the moon!

Literally displaying the moon phases and such.

Seriously though, check out the teacher's notes for info about forking on GitHub.

If I click this star, I see that I must be logged in.

So I'll go ahead and do that.

The username is user and the password is password.

After logging in, I can search for that zip code again, use the same one, 60657.

And when I click the star, it is added to my favorites and

I see that flash message indicating that that is the case.

I can also look at my list of favorites by clicking on the My Favorites link.

And there it is, Chicago, Illinois.

And that's about it for the project as it exists.

Now let's switch back to IntellJ and take a spin through the code.

I'm going to collapse this panel here at the bottom and

the first thing I want to point out is the software stack that we're using.

I'll open the Gradle build file, build.gradle.

So I can point out the dependencies as they apply.

So let me scroll down to those dependencies.

I'll hide this tip here.

Let me scroll down here and as you can see this is a spring app

that uses thymeleaf as a template engine and hibernate as an ORM.

Spring security is present here for user authentication.

And notice that I've listed h2 as a runtime dependency

since we aren't leveraging the library in any of our source code.

The tests compile dependencies list dependencies that are part of the class

path for testing source code which is the main subject of our workshop here.

The first two dependencies give us the libraries necessary for

testing a spring app and spring authentication respectively.

That's the spring boot starter test dependency and

the spring security test dependency.

The next two dependencies give us a library called dbunit and allow us

to integrate that testing library into spring, in order to test our data layer.

We'll get to this at the end of the workshop when we test our DAOs.

And last but not least, junit.

I think that one speaks for itself.

Now moving on to the application code, we have a layout of an MVC application.

As you can see, if I go to the main package here, a com.treamtreehouse

package, I’ve got an MVC application here with packages for models,

that's the domain package, a directory for thymeleaf templates is the views.

That's under Resources > Templates.

And a package for controllers.

That's under web, web.controller is the package there.

This app also implements the service DAO pattern as you can see with packages for

services and for DAOs.

One note about our services is that included in these are three services,

the geocoding service, the places service, and

the weather service you can see down here.

All of which leverage external APIs using Spring's REST template.

Check out the teacher's notes for a more on REST template.

Essentially, that allows us to easily communicate with external APIs.

And one thing worth pointing out about the DAOs is that we are leveraging Spring data

JPA.

Let me show you that here.

If I open the UserDao,

I see that this is an interface extending the CrudRepository Interface.

And I don't actually have implementations in the Dao package.

I only have interfaces and this is because Spring data is going to generate

the implementations of these interfaces when I boot the application.

Now the last thing I want to point out is that for

authorization, that is checking user roles, I'm using the pre-authorized

annotations in place of configuring the Spring security filter chain.

Let me open the FavoriteController and show you what I mean.

What we can do is apply the pre-authorized annotation to enforce

authorization before beginning the execution of the controller method.

And notice here I specify the authorization method I'd like to call

the hasRole method.

Here I want to ensure the authenticated user has the ROLE_USER role.

Okay that'll wrap up our speedy breeze through the application.

Before moving on to the next video I highly suggest you take a few minutes to

look more thoroughly at our application code.