Okay, here we are back inside our algorithm project.

In the last video, we created a test case, and we called it BasicTests.

We're gonna continue our work in there.

What we wanna try is something a bit more realistic than the last batch.

So how about we test this other method, here,

inside our Playlist class, this method down here.

What we're doing is we're gonna take in a dictionary of RGB colors and

we're gonna output a UI color.

As we see in the line above here within the init method,

we're gonna use that to set the background color.

Now for this test let's send a dictionary that we init in our set up

through the method and then make sure we get the results we expect.

So we'll head back over to our test case.

And let's add some properties.

Now inside our set up method, let's give those properties some values.

We can also set those properties back to nil in our tear down.

All right we've set the stage, now for the action.

Let's create a test which passes our color dictionary into the RGB color method and

checks that our result is the expected color.

We'll give ourselves a little space right here.

Okay, so here notice we're using the XCTAssertEqualObjects.

If you just say Equal, it won't work,

you need to use EqualObjects because we're comparing two UI color objects.

Now we'll just take one moment, and figure out why we're getting this error here.

There we go, we just had to expose the method in

the interface of Playlist, so Playlist.h.

Okay we can run our method now,

And great it passes.

Now you may be thinking Gabe that was hands down the worst magic

trick I've ever seen.

It's like I saw you stuff the rabbit in the hat before the show,

it isn't quite magic when you pulled it back out.

Well you're right, but here's the important part.

Let's say someone else on your team was cleaning up your code one day and

they thought they found a typo.

It was right down here in the Playlist.m, they said it looks

like you misspelled alpha it's actually spelled with an F.

Well when they did their code would still compile just fine and

then they merged into the main branch again just fine.

Well luckily the next time you ran this test

You'd find that it fails.

You see the resulting color won't equal the expected color,

since there is no key spelled alpha, A-L-P-H-A anymore.

So the resulting color wouldn't be right, it wouldn't match this key value here.

So luckily the unit test would catch that issue and

plenty of others before users start seeing transparent background colors.

And the color would be transparent, of course because it would just insert 0 for

the alpha value, which is transparent.

So two more things to note, the first is this,

the little issue we just uncovered points to a possible way to improve the code.

Namely by using constants rather than hard coded strings, here and

here in our original method, you could use enum's or constants to make

sure that you don't have string matching errors and spelling mistakes there.

Secondly, this particular test would fail but if you had another test,

let's say to ensure that the color was not nil, that one would still pass.

The color would still exist, it just wouldn't be the color you want,

it would be a transparent color.

This highlights the importance of writing a lots of unit tests even for

a single method like our color from dictionary method.

Since there are lots of ways a method could fail though often not fail so

completely that they just return nil.

So since we know that that test fails, let's go back into our code and

see why it failed.

It failed because we misspelled alpha here, or a colleague did, and

then we can test it again and make sure it passes.

Well that's funny, it didn't pass, let's go see why.

Okay great, it passed.

Let's try one more just for practice, shall we?

We'll stick with the same method since we know you often need to test the same

method from several perspectives.

So this time let's be sure that if we have a color dictionary that is missing

a value, as in completely missing one of the color or alpha elements in the array,

that we'll get nil back instead of an initialized UI color.

So we could write that like this.

Now inside we'll define our color dictionary array

without any green key value pair at all.

And as a result color,

which is the result of passing our

dictionary into RGB color method.

So here, we're going to test if we run our colorDictionary that we created

here without a green value through our method, we should get Not nil.

The test fails, it looks like the resultColor is NOT nil,

we did get a color back.

What the heck, is our test broken?

No, not at all, in fact this test just proved how useful unit tests can be.

Well, much like our misspelled alpha key from a moment ago,

the RGB method treats a missing value as a zero.

So it simply creates an RGB color with zero for the green value.

So what should we do?

Well, the best answer is one that should be determined by you and

the designer for the app.

But one idea would be to create some code inside our RGB method to return a default

color, probably one that would look good with the design of the app

in case that ever encounters a dictionary without the right values.

A really basic fix could look like this inside our RGB method.

So what we're saying here is if our color dictionary has less than four items in it,

let's just return this default color that we created here.

Now of course, this doesn't say which one is missing and

you might wanna do something much more elegant than this but

it sort of gets to the heart of why these can be really helpful.

We'll run it again.

And it fails again what's going on?

Well what's going on is that in the course of creating a test and

thereby discovering the limitations of our previous code,

we've now changed our code to be a bit more robust certainly not bullet proof.

But in actuality we now want to test that it is NOT nil because we just

came up with a way to return a value even when it's missing a value.

Now let's try it.

Okay great, now it passes.

So we know that if we send in a dictionary with a missing value, it won't return nil,

because it'll give us our default color that we added to that method.

Now just to be clear, this code was never meant to be bulletproof in

the first place, and the fix I threw in was not exactly robust.

If we wanted to really strengthen the RGB color method we'd probably want to build

in some mechanism to account for any missing value of the four RGB or alpha,

and use constants for keys and who knows what else.

I only bring up this example to highlight that the act of writing unit tests in and

of itself will often lead you to look more closely at your existing code,

prod its limits and wrestle with less obvious paths it might take.

It's somewhat ironic that while we strive for

a nice long list of green check marks in our navigator,

it's actually the red X's that will often lead you to the best possible code.

You now have the very basics of unit testing Objective C using XC Test, but

as you've probably guessed, it isn't quite enough to actually test the sophisticated

code we build and support everyday.

Take a minute to review what we've learned with a short quiz, and then meet me in

the next stage where we'll explore mocking stubbing and unit testing SWIFT code.