Everybody what's going on this is Caleb with Deb's Lopes dot com.
And in this video we're going to be showing an example of unit testing with swift.
Ok now I'm going to show you an example of some code that I've written.
I'm going to show you some tests that I wrote for that code and then I'm going to show you basically
how a logic error could have been introduced in our application and how my unit test would basically
prevent that from becoming a problem or would basically catch that issue.
So I'm going to pull open a playground that I used here and what I've done is I've imported X C test
which has X codes.
Unit testing platform.
And what I've done is I've basically created a simple class called post.
Think of this like an Instagram post or a Facebook post or even like a tweet.
Of course it's a very simple and incomplete example because there's only a time variable and a time
ago variable.
Think of this sort of like the time stamp of when it was posted and that time is belonging to this Inam
which has different units of time.
Seconds minutes hours days week month year.
OK and they're of type string with a raw value of basically the string representation of themselves.
So we have time ago we have time when it's initialized both those values are set.
Then we have a secondary class called time manager and basically the time manager has a function called
display time ago for post.
OK.
And what we're going to do is pass a post into that function.
We're going to basically set a variable or I guess a constant called time ago and we poll the time ago
value from our post.
We have a pending message of s ago you'll see why that makes sense in just a second.
And then what we do is we return the time ago.
OK the display message so string version of time ago because time ago of course is.
And so if it was you know 24 seconds 24 would be the value here.
Then we add in a space programmatically then we take the time k the raw value of whatever the time is.
So if it was seconds this would be the word second.
And then we add the pending message s ago when it prints out we get 24 seconds ago that's where the
space go comes in.
It depends to the end.
Now we have created an instance of post we've passed in 24 the time a unit is seconds so 24 seconds
ago and the time manager is instantiated and then we call time manager dot display time ago for post
and we print the returning value because of course this creates a string when it returns.
Now this is our implementation code.
Think of you know if you had it in a project or something and now I'm going to show you what it looks
like when we actually create unit tests it'll be inside of an X code project.
But the code is the same.
So I've created a separate class called time manager tests and these tests are basically going to be
for our time manager We're going to test all of the methods and whatever in our time manager class.
Now it is going to inherit from X-C test case that is going to be a must every time.
And basically what we're going to do is we're going to utilize a function called set up and a function
called tear down.
We're actually overriding them from the test case.
But what happens is whenever our tests are run every time a test is run set up is called.
And at the end of the test tear down is called now a set up is good for basically creating instances
of things that we're going to need that we want available at a larger scope.
OK so time manager we want available throughout all of our tests for a time manager.
So we create a variable here and we set its value in set up.
Then when we tear it down we're going to go ahead and set time manager to be equal to nil.
We're basically just going to you know instantiate it and then DISTANCIA it.
That's not a word but you know what I mean.
After the test runs we have a fresh instance every single time.
Now our test here is declared with a function and the beginning of the function is test.
That's how X code knows that it is a test and not another type of function.
So test time display.
I like to write the word or are I guess what we're testing directly after test.
So we're testing the time display and then at the end I put a little underscore and then I say what
the expected result should be it should return a pending message for time.
OK.
And then inside of this test what I've done is I've created a separate instance of post.
I have basically said 58 minutes.
That's what I've passed in then we have created another constant called time ago message that basically
uses our manager that's instantiated upon set up then we call display time ago for post and we pass
in our post the message that gets returned should say 58 minutes ago.
And that's where we use what is called ex-city assert.
There are lots of different kinds of ex-city assert now not just equal.
But there's also LCT assert not nil.
And that verifies that something is not nale as it as you might expect.
There is a certain bill which says yes that is nil.
And you know we could test you know if a value has been properly cleared out or if a property is coming
in as nil or if it is not nil I mean now there is a assert true or false except assert no throw except
assert.
Less then greater then there are a lot of different assertions we can make and basically what we're
saying is we are asserting that a certain thing is true.
OK so if something is false we can assert that it is false.
But what I'm doing is I'm asserting to make sure that this message comes back saying.
58 minutes ago.
Then at the very bottom I called time manager tests default test suite and I run the test.
Now when I actually run it you'll see that my post here 24 seconds it does successfully print out 24
seconds ago.
And our test suite here says the test started the test took point 0 0 3 seconds and we executed one
test with zero failures zero unexpected in zero point zero three seconds.
So that means our test passed.
It means that the message that came back was equal to what we were expecting to get back.
And that means our test works.
K.R. code is good.
Now this is where I'm going to introduce a problem into our application.
OK.
The thing that we're going to do is to show maybe if a junior developer came in and they wanted to change
the code K they wanted to modify it and maybe they thought just you know incorrectly that this already
had all of the values at the end.
I'm going to undo that because it doesn't.
But let's say they thought you know 24 seconds ago they thought Oh it already has the s.
So I'm going to go ahead and this shouldn't be here let's get rid of that code.
So it just says a go at the end.
And of course you can see what printout is wrong.
But look test suite started the test begins.
And look at this example playground error.
Test time display should return a pending message for time ex-city assert equal failed 58 minute ago
is not equal to 58 minutes ago it was working.
Our test passed but now our test fails.
So that means hey there's something wrong in our code something that did work.
At one point now fails.
And so I can look at this error message and say hey 58 minute ago is not equal to 58 minutes ago and
I can go back up here and I can say OK so this function that's supposed to be you know creating the
proper message here.
Oh the appending message is missing s space and now I can run the test again and you'll see all tests
pass.
The code is good so that caught that problem.
If I were to build and run my app the thing that's tricky is that this will still run right just because
the tests fail doesn't mean my project won't run.
If I were to print this out maybe on Instagram below my post if I posted it 24 seconds ago it would
look super unprofessional if it said 24 seconds ago with no space.
So while it will still run it will still successfully compile.
This could accidentally get pushed all the way to production without anybody noticing.
If there weren't unit tests which is why unit testing is so so powerful.
This is a very simple trivial example but there are plenty of instances where things like this could
happen where you could introduce something that technically works but is very very not what you want
to do.
Like this displaying unprofessional text but imagine it was something as simple as this or imagine something
as complex as authentication problems or you know persisting user data things that are a very very big
impact on user experience.
Imagine if those you know successfully passed the code works looks good but you broke something that
did work in the past so that's why unit testing is super powerful.
It helps us to prevent really stupid errors in the future by basically creating a backup of all the
code that works in the past with all the tests that pass so that in the future when things are implemented
we make sure all the tests still pass and make sure that everything still works the way that it's supposed
to.
So unit testing is amazing and super super helpful.
I'm really excited to teach you more about it.
So let's go ahead and let's fix our code here.
Make our test pass and let's head over to the next video.
This is Caleb with Dev slopes dot.com.