Everybody what's going on the scale up with Dev slopes and in this video we're going to learn how to
write tests for view controllers you can basically create an instance of if View Controller run test
on it and even do things programmatically like send the actions for certain buttons to push so that
you know that your buttons work on your controller without you even having to run and test it yourself.
Very very cool stuff.
So let's go ahead and pull up in our testing project here and this is our test for our calculator manager
model.
But why don't we go ahead and right click on walk Helka Aroney tests and click new file and another
unit test case class.
Except this time we're going to name it calculator View Controller tests.
And of course that's going to be a subclass of X-C test case.
Click next and then save it.
And now we get the same thing we did before we get to example tests we can delete.
We don't need them and we get a set up and tear down function k very cool.
Now of course to access our actual app project we need to type at testable import wall Kalka Aroney
And now we have full access which is very very cool.
So what we're going to do is we're going to have to think OK what is the system we're trying to test
here.
It's our view controller.
So we're going to go ahead and create our system under test.
Var Sutt and it's going to be calculator View Controller.
OK.
Put an exclamation mark at the end saying yep we are definitely going to be in stanching instantiating
this and giving it a value and we're going to do that in set up.
So I don't know if you already have gone through and looked at this you probably haven't but this view
controller is of type calculator view controller but it also has a storyboard ID of calculator View
Controller.
And we're going to use that.
So go back into your tests.
Open up the assistant editor and you know what.
While we're here why don't we go ahead and load up the project and then go to the controller so we can
look at these side by side.
So let's go into our view controller tests and here we are.
So in order to use the storyboard to instantiate a view controller we need to first create an instance
of our storyboard so type let storyboard equals you storyboard and the name is main right main but storyboard
It's right there and the bundle we don't really care about so we're just going to say nil.
And then what we can do is we can instantiate this view controller.
So we're gonna instantiate sat by typing storyboard dot instantiate controller with identifier.
Now our identifiers the one we set and it's just the name of the controller calculator view controller.
But this just creates an instance of view controller we need to force it to be of type calculated controller
so go ahead and type as calculator controller just like that.
Now we need to do is we need to basically set our system under test to be nil at the end of the test.
So type sut equals nil and that's going to tear down and make it nil so that every time we run the test
we have a fresh instance which is exactly what we want.
So let's go ahead let's write our first test and let's begin let's think we have our little calculator
here.
What do we want to test.
How about adding values.
Should append those values to our array and label here.
Let's let's test that out.
So let's type phunk test adding values.
That's what we're testing.
And the result is should append and update label.
And I'm going to go ahead and fix that capital P there.
Cool.
Awesome.
So let's go ahead and let's access our system under test.
And the cool thing is right in here we can access all of our buttons.
So let's go ahead and let's just pretend that we're going to go ahead and add 2 5 K to make 25.
So let's type set that 2 button and here's what we can do.
We can type send actions for a particular UI control event and these UI button outlet's if we push on
one what we're doing is we're calling touch up inside.
So basically by typing this we are simulating what happens when you actually touch the button.
Very very cool we don't even have to do it ourselves.
It can test this in just one second or less than that very very fast.
So what we want to add.
OK so we we tap the two button we want to add another value so type set five button ok send actions
for Dot touch up inside.
So we have now pushed 2 and 5.
And now what we want to do is we want to actually check to see is our label actually 25.
We've written code to this but we're basically testing the view controller to see if it's displaying
properly when the user interacts with it.
So we can type ex-city assert equal sut dot and this label here is called value label.
So we can type set that value label text and it should be equal to 25.
So let's go ahead and let's run this test and let's see if it properly is doing what it's supposed to
build and run and test as well.
So there we go it tested perfect and it's testing.
And did we pass that seeded with bats.
Are we going to pass.
He's going to let me pass.
Oh no.
So here is a problem.
Check it out.
What is the error.
All right.
So the test started then we get an error and it's going to tell us hey unexpectedly found nyl while
unwrapping an optional value.
Now if you have ever set up an action or an outlet and linked it to something and then deleted it or
deleted the item and it was still referencing it it basically shows up as nil because it's not yet instantiated
but items linked by outlet's or Iby actions are instantiated by the view controller upon which they're
connected to.
So we actually didn't do something that's very very important.
Now if you think about it when your app launches feuded load is a very important function that's called
because that.
Well I guess feuded load you will appear any of those basically are called different times and you can
basically set up things to be you know be initialized to be set up initially.
And we have not you know called feuded load because this isn't running on an actual device.
So what we can do is in our setup function we can type set dot load view if needed.
And it says load's the view controllers view if it has not been loaded which it never does so this loads
it for the first time.
Now let's go ahead and try our test.
And now we should have full access to our buttons because we have called feuded load and everything
is initialized properly.
So here we go it's testing and success our test passes our buttons when we push to five.
The label is successfully update the label is successfully updated.
And you know what I just realized our test is testing two things.
So let's just make sure should update label.
That's what our test is for if we wanted to check the the array deep within the calculation manager
we should have written a test for the calculation manager.
And you can always go back and do that.
It's up to you.
So let's keep going let's write a few more tests here.
Let's make sure that the calculation if we actually do a calculation that it's going to actually you
know perform a calculation and update the label the right way so phunk.
How about test equals button and what is what is our expected result should perform calculation and
update label.
OK.
There we go.
And so what we're going to do is we're going to run through what a user would do in order to actually
you know pass in values.
So I'm going to go ahead and just use the same thing here.
We've passed in a two and a five.
Now we're going to do sut maybe about subtract button that send actions for touch up inside.
And so we're doing 25 minus sut.
Dot How about I don't know 5 or well I guess 5 button whips that send actions for a touch up inside.
And now we're going to call sut equals button because we have typed to 5.
So 25 minus five.
And when we push equals we should get a particular result should be 20.
So let's type ex-city X C-T assert equals Surt dot value label dot text and it should be equal to a
string with 20 inside.
So let's go ahead and build to get our little diamond here and run that test.
Make sure that it works.
OK let's see we're testing and it comes back.
GREENE It works.
Let's just make sure that all of our tests work by pushing command you.
You want to run all of your test as often as possible to make sure that one test didn't break another
or that if you changed code it didn't break your other test both Test Pasto So that's great.
So our calculation is working flawlessly.
That's awesome.
How about this.
Let's test if changing the operand actually changes the operand so phunk test operand buttons should
show.
Change operand when tapped.
That will work.
So let's go ahead and let's make sure that our operand actually changes.
Let's type sut dot.
How about for Button.
Let's say we type we want to do 4 plus 4.
So send actions send actions for touch up inside.
And if we're going to do plus we're going to go ahead and type sut dot.
But let's say we accidentally type the multiply button first.
So touch up inside Surt dot and now we're going to type the add button does send actions for a touch
up inside.
Then we're gonna type the four button again but send actions.
And so now what we've done is we've pushed the four button with accidentally push multiply wups push
the add button then push for.
Now we're going to make sure.
Oh whoops we've got a call equals that dot equals button.
Send actions for touch up inside an ex-city assert equals.
OK we're going to test the label.
So value label that text and it should be 8 right.
Four plus four.
So let's go ahead and build this.
We get our testing diamond and let's run that test let's make sure that this works the way that we are
hoping.
Testing testing and it works so changing the operand when we tap it actually successfully modifies the
operand.
That's amazing.
So let's see how about let's test our a button.
So phunk test we'll just call it the clear button should clear label because that's what we should do.
Clear the label and let's let's check that out.
So let's see sut dot 8 button send actions for touch up inside.
So we tap the eight button let's do Sutt dot seven buttons send actions for touch up inside.
And now let's do it.
A See button that sends actions.
And if we did this properly our value in our label should now be zero.
So ex-city assert equals and let's go ahead and say some value label dot text should be zero.
OK let's run that test and see how we did launching our tests running our tests and it passes.
Yay.
But let's think OK.
The label shows up but if I want to make sure that all of my values are zero.
Let's make sure you know everything works the way it's supposed to.
We don't have to because we've already done this in our calculation manager test that's a test for our
data model.
So when clear is called K all the values are set to zero.
And we know that when.
Whereas our test here we know that when the clear button is pressed in our code AC button we call clear
value.
So we already know that works.
So we don't have to worry about it.
Now you could write a test.
It's up to you but it's not necessary.
Now we have written tests for adding values.
It updates the labels calculations performed properly operands change properly labeled clearing happens
properly.
Now if anyone were to come in here and change anything right like maybe I just said OK calculation manager
pen let's set everything to four.
OK.
Now for if you look at the opera ending that means that basically it's going to be forced.
Everything will be forced to divide.
And if I build this the code technically works.
So the build succeeds but if I push command you to run all my tests.
Watch what happens.
The test will launch.
They're going to test but we're going to get a failure in our test.
Check it out.
Adding value should update label to five.
OK it didn't work OK because we did not properly add in the number.
Oh actually you know what this is for the number button I just realized so we're basically forcing every
number to come in as the number four.
So of course this test passes that means I broke all my buttons.
This of course failed because I did 4 4 4 instead of two 5 and five.
So now if I go back whoops and I fix that.
Let's run our tests and check it out.
The test will launch.
They'll run and they'll be fixed.
This is why testing is so so so so helpful and if you write a lot of tests for lots of things like this
you'll be much much less likely to run into headaches and problems later on.
So this is basically how to test controllers for various things.
You of course can even test things whether you know a certain view appears on the screen.
UI testing involves the actual display of information on the screen visually.
And we'll test that later.
But this is how you tested your controllers.
It's very straightforward.
Basically you think through what the user would do.
You make sure that that action actually results in the result you were hoping for.
Very very easy stuff guys but very very very powerful.
So let's head over to the next video.
This is Caleb with Dev slopes dot com.