[MUSIC]

Now that we know how to test, it's time to start looking at the more difficult

question, and that is what to test.

Remember, this is the part where we developers haven't been replaced yet.

What we've looked at thus far is what is known as the happy path.

You should be able to determine what that path is by asking yourself this question.

If this code ran correctly, how would I know?

I'd like to take a moment to practice a skill once more.

Along with all the other parts we learned in the how to test stage.

Why don't we take a look at the other component that we broke out, the chooser?

Specifically, let's take a look at the alpha numeric chooser.

Okay, so we will press the double shift.

We'll do Shift, Shift and then I'll start looking for

alpha, there we go, AlphaNumericChooser.java, there it is.

Okay, so let's go over some key concepts here.

First off, this extends a class called AbstractChooser.

Let's open that up too.

This might be the first time you've seen this keyword here, abstract.

What this means, basically, is that the class cannot be instantiated.

You must extend it and

override some required methods that are also marked with the abstract keyword.

See the icon over here?

This shows who uses the subclass, and

then down here this shows who implements each one of these methods.

So this one is an abstract method.

Okay, and you'll notice that over here it doesn't have any definition.

Just says what it throws.

But it's abstract, you must extend and override this.

Wow, so this class, this abstract class also has an inner class named Location.

Inner classes are helpful sometimes to create classes that depend on certain

variables in a surrounding class, or parent class.

Do you see here how it's using maxRows and maxColumns from the AbstracChooser class?

The AbstractChooser takes a maxRows and a maxColumns and that's the outside class.

And the inside class here, this location, uses the maxRows and the maxColumns,

because it's in the right scope.

Also look here, the constructor for Location is protected.

So no one other than the code in this package can create a location, only us.

So you've used something like this before, remember map.entry in the map interface?

It looks like all this is doing is grabbing a row and

column, validating that it's allowed, and then returning it.

It's a pretty dumb object, right?

Now, you might not have seen any of these concepts before, and

I wanted to use them to show you and reiterate, that doesn't matter.

You are testing the behavior, not the implementation, remember?

We're not gonna test that all that stuff is true,

we're just gonna test the behavior.

So let's just do that, right?

What is the happy path that comes out of here?

Well the public API says one thing,

It says locationFromInput, and it returns a location.

So how about we make sure that if we choose something valid

it returns the expected row and column, sound good?

So we wanna test the elementation specifically, so

let's switch over to the AlphanumericChooser.

So see we can mouse over here and here we'll jump back over there?

Cool.

So, let's create a new test over here, so again that's Cmd+Shift+T or

Shift+Ctrl+T in Windows.

And I'm gonna choose Create New Test.

JUnit four, it's got the right class name, it's in the right passage.

This time let's go ahead and let's make a before method.

And let's just go ahead and have it generate this test.

We're gonna rename it, we know that it's gonna give us a wrong name.

So let's go ahead and create that.

First things first, let's rename that.

Let's say validInputReturnsProperLocation.

All right, so how about in the Before up here

we have it create the chooser for us, right?

So we're gonna say, chooser= new AlphaNumericChooser.

And remember that that takes the max rows as 26 rows for the alphabet,

we'll just do that.

And then 10 columns that's a big vending machine.

Let's do that.

And it says can't resolve chooser, so

let's have it go ahead and create the field chooser for us.

Cool, okay, so we've got the arrange covered in the before method there,

now let's do the act.

So let's go ahead and get one of those locations out right,

that was that inner class.

We'll call it loc and we'll use the chooser that got instantiated and

we'll say location from input.

And let's just pass in the input, we'll pass in B4, and

now let's assert that we got the right location back.

So we want to make sure that B4 returns the second row,

right, A, B, and the fourth column.

So that's array indices 1 and 3, right?

Okay, so we're really only testing one behavior, but

we're probably gonna do it in two assert statements.

That's okay because we're testing the behavior.

There's two assert statements but it's the same behavior, right?

Okay, so let's do an assert,Equals, and

remember it goes expected and actual.

So we expect 1 for the row.

And we expect 2, or sorry, we expect 3 for the column, right?

So that's B4.

Cool, let's test it, awesome.

Here we can see our new test is showing up here and it looks like it passed, great.

It's kinda handy sometimes to always make sure that it fails too.

So cool, we can make sure that it fails.

You know what though?

Let's think about this, what if one these assertions,

one of these two assertions fail?

It's not gonna be obvious how it failed, right?

Let's break it and let's see.

All right, so if I say let's change this to 3.

It's just gonna say that it's an assertion error and expected 3 but it was 1.

But it's not clear, there's two assertions, not clear.

Is it talking about the row or is it talking about the column?

So this is a great use of the optional message parameter.

So what should do is you put on the positive version of what was expected.

So let's do that, so this would be here, this would be the proper row and

put in here, this is the proper column.

Okay, and then we refresh and run again, and we'll see that it says proper row.

So now, somebody, if this test fails,

they'll know, because of that message that we put in there, what that is.

It's a nice touch, right?

Fix that back.

There, now we know what's going on.

There are definitely more descriptive assertion patterns that we can use, and

are available to us, and we'll touch all those briefly here in a bit.

Looking at these class, if we come back here to this class,

there are some exceptions that are thrown in here.

We should probably try to test those too.

What a happy path we've found.

Exceptions are also part of the happy path.

So after this quick break,

let's learn how to properly test all expectations of our public facing API.