Life sure would be easy if everything always stayed on the happy

path, wouldn't it?

But we know, this isn't the case.

Part of the awesomeness of unit tests is we can plan and

check on what happens when things don't go so well.

Actually before, they don't go so well.

Now, so far, we were just kind of testing what was already in place, surrounded

around errors that I had anticipated or that techs had pointed out directly to us.

However, you can also use tests to explore how things might break and

what it looks like when it does.

So, how do you find common ways to break stuff?

Well, guess what?

I got another handy pneumonic trick that I picked up from Jeff Landers'

awesome book "Pragmatic Unit Testing".

Now, I've found that these are hard to think about all at once.

This little memory tool will help you run through them quickly.

Unfortunately, we're not going to be able to cover all of these in detail, but

we'll explore them a bit.

And I dropped a link in the Teacher's Notes, if you want more info.

Ready?

So, when you wanna think through what might go wrong around the edges of

the happy paths, these are called boundary conditions.

This is where the possible problems are usually lurking.

Try to remember the correct way to find them.

What happens when the unit receives data that doesn't

conform to the expected format?

Is the ordering of the values returned in the expected order?

Applications where listing results in a certain sort order

should definitely have tests proving that this works as intended.

Make sure you check the range.

What happens if you go below the minimum or over the maximum value allowed?

Does this unit reference any other code from another unit?

Is that other code unit tested?

Remember that existence is important in most units.

Are things allowed to be null?

What happens if they are?

You should check the different possible number of elements in a group or

cardinality.

Related to existence, always check what happens if there are zero.

What happens with a single value?, what happens with multiple values?

This is often called the zero one in, because none, one and

some usually produce different expectations.

Remember to always take time into account.

This can be relative as well as absolute.

Like for instance, sometimes applications require things happen in a certain order.

What happens if that doesn't?

Check the teachers notes for more about these.

Let's go see some of these boundary checks in action.

So, how about we write some tests for the bins?

Now, text was pretty particular about these should work.

Remember, he wants to make sure that you keep the same items in the same location.

So, let's look at the bin class.

So, it looks like,

if we restock here it looks like we have a heavy path just doing that, right?

So checks and makes sure that if it's not empty the name equals

get item name, then, it doesn't equal it, then it says it can't restock.

And it throws an IllegalArgumentException.

Let's make a test.

So, I want to do Command+Shift+T.

And it can't find one, so I'm going to create one.

Let's go ahead and leave a before in there.

And okay.

So let's go ahead and make a new bin.

Say, ten.

Right? That's how many

items can be stored in there.

So, go ahead and create a field.

Bin.

There we go.

All right. So,

let's make a test where we attempt to restock with different items.

Let's do that.

So, we'll say new test,

and we will say

restockingWithDifferentItemsIsNotAllowed.

Okay, so we will first, let's stock it up.

Let's put some delicious Cheetos in there.

Was not product placement.

And then, let's also put some delicious Doritos as well.

There.

Okay.

And let's, well obviously we know that it throws an exception, oops.

Let's make it throw that exception as well.

So, it was an IllegalArgumentException.

Cool, so let's run that, make sure that's working.

Awesome, our bin test passed.

Okay, so that was using, this Bin here was using

getItemName, which checks to make sure that things are empty.

So, we need to be careful about that right because the item, it might be empty.

So we need to make sure that every place that we use that, we need to check for

cardinality.

Remember that?

Where we check for zero, one, or more?

So, we need to make sure that anything that's looking for

information about the next item in the bin returns the right thing.

GetItemName here is totally protected, see how it checks for empty.

But why don't we check for what happens if there's no items in the bin and

we check the price.

What should happen?

Let's see.

It should return zero right?

I hope so.

I mean, I know that you can buy ghosts on Ebay, but we don't wanna be charging for

nothing, so let's add that edge case.

So, let's flip back to the test.

Let's add that edge case for what happens when it's zero.

Let's make sure.

Let me say when empty price is zero.

So, we'll just go ahead and because it's going to start out empty, so

say zero bin get it Item price.

Let's see what happens.

That should happen, right?

Testing this edge case here, oh!

We got one!

I mean, well we found one, that's not a good thing, but it's good for

what we're doing right now because we're gonna fix this, right?

So, let's go back to our bin class here, and let's take a look and

see why is it returning a null pointer exception.

Oh!

Because it's just doing a peak in the peak here is it's chain is gonna return a null,

and if you call get retail price a null, Null pointer exception.

We don't want that.

So, let's go ahead and what should we do?

It should return 0, right?

So, let's just fix the code here to make the test pass.

So, say if is empty, let's return 0, right?

We can do that, we can return 0 in the middle of a, oops.

And then, if it's not empty, obviously,

there's 1 in there it can get the retail price of what's there.

Let's go ahead and run that.

All right, our test passed, good job.

You know what?

I saw in there.

Let's make sure that this never gets broken,

that nobody thinks that this line should just go away.

So, let's go ahead and add the test for that.

Again, that's pretty easy.

New test method, and let's say

whenEmptyNameIsNull, little probably more specific.

Maybe we could word that better, but let's make a new test.

So, let's use this assertion, there's a lot of assertions on here and

we haven't really played with too many of them.

Let's do assert, no.

Oh, look at that, there's one in here for that, exactly what we want, and

it just takes the object or a message in the object like we saw, so

we'll just pass and get item name, right?

So, that should make sure that, that's pretty explanatory in what it's doing.

Bam!

Awesome.

Here we've used another assertion in the awesome assert class.

There are a ton here, and there is an even more expressive language that is outside

the scope of this class called Hamcrest, which is an anagram for matchers,

where you can match on these different things.

Check the teacher's notes below for

more info on these powerful descriptive assertions.

So, let's try the boundary check surround range.

Remember, the second R in the correct pattern.

So, range-wise, we know that there's a top limit, right?

It's ten.

I know that there should be code in place to stop overstocking.

Well, why don't we just rock out a test really quick and

see what happens when we overstock?

Because it's faster just to write the test, right?

So, let's just say over stocking not allowed, see what happens.

So, we'll do a restock delicious Fritos, I'm getting hungry,

twenty six hundred, one hundred, and fifty.

Okay, so let's run that.

Oh, that's a very descriptive error message.

It's dynamic, it says there's only 10 spots left.

That would be nice to test, wouldn't it?

Since we're taking the time to make such a dynamic message,

we want to make sure that the message actually says what we want it to.

The current way that we're testing exceptions,

we just use the expected value in the at test annotation.

Well, there's a pretty powerful tool in j unit called rules.

Let's touch on them here briefly and then,

I'll show you in the notes where to learn more about them.

So, rule allow you to redefine behavior in each test method.

There is one to do exactly what we're talking about here.

If you wanna access the exception thrown inside your test and

still ensure it's thrown, you wanna define a rule.

So, what you do is make a rule with a rule annotation just like this.

We say @Rule.

Public.

And we're looking for ExpectedException is the name of the rule.

And we're gonna name it thrown.

You can name this whatever you want.

And by default we want it always to be none, right?

We don't want the exceptions to be thrown unless we specifically say so.

So, in here, in our test, in this overstocking, we want to arrange and

we wanna say that thrown.expect, and we expect right down here, right?

Let me get that out of the way.

We expect illegal argument exception to be thrown.

Illegal argument exception class.

And then, we also want to specifically expect the message.

Expect that there are only ten spots left.

So, grab that.

Put it here.

Here we go, I'm gonna run it.

And boom, it passes.

And note that it doesn't have the expected appearance inside

here is where we're using the rule.

It's pretty powerful, right?

Now we're making sure that with the value goes out of range that we catch the error

and that the dynamic message provided is correct.

So, let's take a look again at our alpha numeric chooser test.

So, let's alpha numeric chooser test.

There we go.

Our choosing wrong input test here is a great example of a conformance test.

The C, right?

We have another range test on choosing larger than max columns is not allowed.

Hey, let's check the range of what happens when we use more rows

than there are letters in the English alphabet, which is 26 right?

So, we'll make

constructingLargerThanAlphabetNotAllowed.

So, we'll just make a new alphanumeric chooser, 27, yeah.

We'll go ahead and run that.

Ooh, maximum rows supported is 26, so again it's a dynamic message.

Why didn't we catch that?

Actually, why don't I put that on your plate to catch and

verify that we get the message correctly.

Boundaries are super helpful when your trying to find out

how your code might break and they're especially helpful when considering

when writing tests first by using test driven development.

Now, we had already done a pretty good job of thinking through

plenty of possible bugs but the boundaries will help you think through even more.

There's tons of good stuff in the teacher's notes.

Glad you got a change to play around a bit with rules, they are super powerful and

you can also write your own.

There's actually third party rules that you can use.

Someone wrote one that lets you fake out the input and

capture the output from a console based program.

Speaking of faking, one of the important pieces of test that we haven't covered yet

was mentioned in both of our acronyms.

First and correct.

The I is isolated and the second R reference.

So, how do we make sure that our tests are isolated?

The answer, my friend is test doubles.

And it's part of a larger discussion which is what should we not test.

Let's go learn about what not to test right after this break.