You've had a chance to see the code base so it's time we dive into some testing.

Now whereas the code you've explored so

far resides in the main source directory, the code that we'll write during

this workshop will live in the test source directory, so let's open that now.

In here there's exactly one package com.

teamtreehouse.web.controller and in that package one class weather controller test.

Let's open that now.

What I'll do in this workshop is show you how to test spring

components starting with the controller like this one then

working our way towards the database by moving to services and finally to DAO's.

Let's begin by testing the weather controller in this class weather

controller test.

Now for each method in a controller we'd want to write at least one test and

even more if we have boundary cases to consider.

Remember those are the special cases that won't happen often or maybe hardly ever.

But we want to make sure application doesn't blow up

in the event that the unlikely occurs at any rate.

Let's start by testing this controller for

what happens when the home page is requested.

So if we open the weather controller.

And scroll down to where the home page is requested which is at the bottom here.

We see that the only thing that this method does is render

the weather/detail template.

So let's make sure it does just that.

First though, we need to set up our mock environment.

So back in WeatherControllerTest,

we are going to have to set up our mock environment.

Now typically when we run a spring application, the overall shell or

container that we are starting is called an application context.

This is a spring container that loads and manages bean definitions,

like the methods that you've annotated with bean in your config files.

Or all those classes you've annotated with controller, service, repository, and

component.

Now, all of this is a bit overkill for our unit test.

That is, loading all these definitions.

We don't need all those being definitions and the extra functionality provided by

the application context just for testing purposes.

If we were to load the context, that would be an integration test.

Integration tests are important but they are not the subject of this workshop.

Be sure to check the teacher's notes for more on the spring application context.

Instead of loading an entire application context here, what we'll do is create

a fake or mock MVC object through which we can run all requests to our application

and we won't need to fire up the entire context which would take more time anyway.

So to begin, let's set up a mock MVC object.

I'll declare it as a field so I can reuse it within the individual test methods.

Private MockMVC, there it is right there, and I'll call it mockMVC.

We'll also need a controller to set up that mocked MVC framework, so

let's declare one of those too.

Private WeatherController that's our controller under test here and

I'll just name that controller.

As you've seen with unit testing in the past we can include a method in J Unit

tests that is sure to execute once before each of the test methods is executed.

Let's use that method to set up our controller and mock NBC objects.

So public void, I'll name it setup, that's the standard name for

one of these methods.

And let's set up the controller.

So I'll create a new weather controller excellent.

And let's also set up the mock MVC object.

Now this object is set up with the builder pattern so

mock MVC builders right here and will choose the standalone set up and

pass to it the controller that we just created and

to build the object and store it into the mock MVC field.

I will call this builders build method.

Okay, time to write our first test.

Again, we wanna test that a request to our home page renders the weather detail view.

Let's name our method accordingly.

I'll annotate this with J units test annotation and I'll call it public void.

And the home should render the detail view.

And I'll say it throws an exception.

As for the test code, we'll start by using the mockMvc object to perform a get

request, so mockMvc.perform And

what we can do here is use the mock N.B.C. request builder's class.

So if you arrow down there you see it right there and

we'll use the get method and in parentheses here the parameter

value we want to pass is the U.R.I. that we'd like to perform a get request to.

Now for convenience, let's do a static import of this

mockMvcRequestBuilders class, all of its methods.

So here we have that right here.

I'm going to move this down here and

do an import static of all its methods.

And I'll be sure to change that second import statement to static.

Cool.

Now I can remove this right here, and

that get method is called in a much more succinct

after this call to the mock NBC's perform method, we can write

expectations which are like assertions by chaining method calls right here.

For example, let's expect that the view name is weather slash detail.

So we'll write andExpect.

And in here, we can use a MockMvcResult matcher and

all say that it's view name so, view it's

name is equal to weather/detail.

Let me put this on a couple lines so you can see it in my code window here.

Give us a little more room there we go let's do that right there.

Okay, let's do the same thing for this mock NBC result matchers methods

as we did for the mock NBC request builders right here.

So I'm going to move that down here under my static imports.

So import static will say all its methods and

I can get rid of this using its static methods quite a bit.

So this allows us to write much shorter code and

just like that we have our first test.

Now let's run it.

I'll make sure to save my file here.

And with the weather controller test editor in focus all use

control shift R to run this test.

What you should get is a panel that pops up at the bottom showing the success or

failure of this test.

And great looks like our test Passes, we got green.

Let me show you one more test before we start looking at mocking objects.

Let's test the weather controller's search method.

So, back in the weather controller class,

let's see what the search method does here.

The method currently accept a URL query string parameter and

redirects to a URI with a path parameter.

Let's make sure in our tests that this actually happens.

So let's go back to the test.

I'll start by stepping out a method according to what I'd like the test to

examine.

So let's write a second test down here.

I'll name this one public void search_ShouldRedirectWithPathParam().

Cool, and in that method, let's perform

a get request to the /search URI, so mockMvc.perform.

And again this is a GET request to the slash search you are I

know what we need to do is we need to add to that query string parameter to the GET

request so after the call to get I will call the param method.

The parameter name is q and the value I'd like to pass is 60657 and

what we expect is that this request

redirects to /search/60657.

So let's do that now let me put this on the next line here .andExpect.

I will say redirectedUrl.

That's another method that comes from this MockMvcResultMatchers class.

So I want to expect that the redirected URL is /search/60657.

I'll put my semi colon at the end here.

There are lots of things that you can include as an expectation.

Check the teacher's notes for more.

Okay, let's run both these tests and see if we're still in the green,

control shift r and let's watch both of our tests run and hopefully succeed.

Excellent, it says all two tests have passed and I see the names of those tests.

Right here.

Now, though we're green, we've only just begun.

Next I'll introduce you to the powerful world of mocking.

No I don't mean giving other people hard time.

I mean faking objects.

You'll see what I mean.