This what's up and what the price as does Snopes dot com.
And in this exciting video we are going to create the logic for the application or the math that does
the calculations and sometimes this is called The business logic if you look up programming definitions.
Business Logic is the code that basically does the thinking and that code is very important and needs
to be tested needs to be well-written.
And so what we're going to do is we are going to create the not only the code to do the math we're asking
to write a unit test your very first unit test so it can be well tested and trust me.
If you have any type of unit tests in your project when you are applying for a job if you're doing an
example project you will get a thousand more points than the other candidates who do not have unit test.
It's very important to companies so this is a good thing to start learning right here right from the
beginning.
So what we're going to do is we're going to select our just look at your project up here and then we're
going to go to Ed. at Target.
OK.
And we're going to add a unit testing Bunuel now.
Before I do that if you created your project with a testing bundle it'll be right here ready so you
know when you create a new project and if you want to do unit tests or you itas We've had ours off.
But if yours is on then you don't need to do this step but I'm assuming that you've done the same thing.
I haven't heard of turnoffs So we're going to go to editor at Target and we're going to add a U.S. unit
testing bundle and we're going to say window shop retests.
Great great great.
All part of this project.
Wonderful.
Awesome.
So now we have unit test as you can see in this folder here.
We have some functions for us here.
So that's great.
So the next thing to do is actually create some code.
So here in the windows shopper I'm going to create a new group and we're going to call this model and
what we're going to do.
We might.
So we might have had this code let's say in a model file on a wage model.
It's a small app but it's fine.
So in this model file We're going to do a new file.
It's going to be a swift file and we're going to call this wage for lack of a better term.
We would assume maybe in the future would add more logic here.
It's going to create this wage.
And what we want to do is create a class called wage.
And inside this class we're going to create a class function class funk.
And what we want to do is create a function that will basically take inputs and then produce an output
basically the math behind this if you can think about it is we take the price of the item and we divide
it by your hourly wage and that's going to tell us how many hours that you need.
And so we want to write a function that does that for us.
OK so we're going to call this get ours.
All right.
I'm going to say for wage to say wage and swimmy of type double.
And then we're going to say and price right now the price the Colon's can be here and of type double
and we're going to return an integer you know because that's the that's the number that says 14 hours
15 hours.
We don't want to say fifteen point five hours because we just want solid numbers.
OK.
And we're going to return it.
All right.
Now maybe you are seeing some new things here.
OK.
Hours for wage why do you have.
Why do you have to parameter names here.
Well what I have here actually is a parameter name.
And then the variable name itself.
So this is more for autocomplete when you're typing in things you can see a readable description if
you like.
All that makes a lot of sense.
And this is the actual variable that you use.
And so you can actually name your parameters like so and this indexes the parameter name space and then
the variable name with the colon and then the type.
OK so get ours and what we want to do is we want to write code to get the appropriate hours.
Now I'm not going to be doing test driven development here where you do want thing you felt you another
thing I felt I'm going to write unit tests the way I write it and most people I know write them which
is you build it out and then you test it.
OK.
And so remember we talked about the math.
It's basically price divided by wage.
But ours is a unique circumstance.
So let's let's do some math here.
Let's say we have an item that's $250 and move this up here $250 and 53 cents.
And let's say we make $15 an hour or 15 50 an hour.
OK.
So that's saying you need to work sixteen point sixteen hours.
Well that's confusing where we don't want to.
We're just trying to make a purchase decision we don't want to calculate mid hours of what we actually
want to have happen is we want the result to be 17.
OK.
Because we know 17 hours guarantees the purchase OK.
And it's cleaner and easier to read and that's the logic that we want.
So what we want it what we don't want to end up doing is we want to round up whatever the value is we
want around up to the next whole number.
Okay.
And so we need to write the logic for that as well too.
So we would do the division math and then we round up to the next whole number so we can guarantee that
if we work this many hours it pays for it and you might have a little more left over but that's ok.
I think that calls for a better user experience.
And so it's pretty simple actually.
So we just say return and what we're going to do is we're going to say seal this is math ceiling.
So it's going to go up to the next level.
So if you give us 15 50 it would go up to 16.
Okay.
And we're going to say price divided by wage.
Right.
So that's what we want.
But the problem with this is it's going to return a double k cannot return double the type int.
And remember the application costs for an integer because that's what we're showing to the user.
So this is easy enough we'll just convert it to an int when it's done.
So in like so.
And the good thing about this is if it's like even five point zero it or get rid of the zero and just
converted to an integer which is exactly what we want.
So that math is not that hard but let's go and write the unit test for now to ensure that it's giving
us what we want.
OK.
So what we're going to do is we're going to go into our window shopper tests and let's just put a function
in here I'm going to say phunk or just say test wage or get our test tests wage for hours test hours
which said tests get hours.
So I'm going to say OK and all we want to do is run some tests to make sure that our code is actually
working correctly.
We read in the code we think it works correctly but how do we know for sure.
So it's pretty simple.
We're going to use ex-city assert and I'm not covering everything in unit tests.
I'm just covering what we need to know for this application.
So ex-city assert and you can assert true or false.
We're just going to say X-C to you sir.
And then pasand an expression because it's just easier for this example.
And so what we want to do is we want to call this wage function.
So wage get hours and remember this is a class function.
So you don't have to create a copy or an object of wage to use this you just wage Dopp then the function
name.
And this is only one function in memory that every instance of a wage is going to use or you can access
from anywhere.
So in here I should be able to type in wage Daut but not at home nothing's coming up.
So because we added the unit tests later on in the project our code files don't recognize that target.
So we need to do is actually go over to our wage file here and open up the right hand side here and
see this little file that's highlighted here.
This is called the file inspector.
Now you have to do is click this target here window shopper tests and it will now let you test and have
access to this wage file.
So now if I go back to window shop or tests I can say wage dot hours and it's now available so we can
start passing in numbers here.
So what I can do is I can say for wage so let's say we were making $15 an hour actually make it easy.
We'll say $25 an hour and the price is one hundred.
So we should assert that the result we get is equal to 4.
OK.
So right because 25 and 200 is for maybe using it.
But Mark we did the ceiling thing where it goes up one well it only goes up one if there's a decimal.
This is this is zero right.
So 25 to 100 is for without any remainder so this should be for for sure.
Let's the one with numbers.
Now what we can do is we can actually run some math here so we can actually run this one right here.
So let's copy this Kamensky and I'll delete it here in a second so we can run another assertion accede
to assert let's say wage that get ours for wage.
And so let's say the wage is 15 50 and the price is two hundred and fifty.
Fifty three by command space again remember sixteen point sixteen.
So using the ceiling function this should be 17.
That's the value we're looking for in our function.
If it comes out true and this works it means that we rewrote the correct code.
So this should be equal to 17 because of the ceiling function which makes it go up by 1.
So this should be equal to 17.
All right.
So what we just done here is we've just written a few tests.
We've met we've passed the numbers here so this is how unit testing works.
You you you call a function and you pass data and you get data back.
That's good code.
Good code is when you pass and parameters and get things back.
Bad code is when you have a bunch of functions that depend on other functions that's called function
dependency and it's very very bad.
Functions that depend on other functions is bad.
Let me say this again this is a protip.
OK.
When building your business logic functions that depend on other functions is very very bad.
You want the modularized.
OK you don't want them to rely on anything.
So you passed data in and they spit data out and that is that's perfect.
It's called functional programming and that's the way you want to build your applications and so we
are testing that.
If we pass in a 25 and a 100 that we get a 4 it's going to assert that otherwise it's going to fail.
And then in the second case we're asserting that this decimal value this way it's 15 to 50 and the price
is equal to 17 that it rounds up.
OK and let's make sure.
So point 16.
You know normally if you were doing that of around a function with around down around.
But we know that it's covering all of our bases because this is below point 5 and still rounding up
to 17 or so we think.
So I think these are two tests and I think there are enough.
What I'm trying to say.
I think we have enough tests here and I need to do to actually run your function here or your unit tests.
Click this little icon right here.
So click the play button on it.
It's going to build it and then it's going to run it.
You always always always want to run tests before you run your code.
So in other protip always run your tests before you run your code every single time.
Test run your tests before you run your code.
That way you ensure that you haven't broken anything and it's testing as you can see up here at the
top and it says tests has succeeded.
Hooray.
And if you're absolutely new to unit testing maybe you're thinking Mark I really don't understand the
point of this.
Like I really don't like my is good so why do I need to test it.
Well here's a perfect reason why.
OK here's the perfect reason why so let's go on to the Google and let's type in Iowa development round
double OK.
I'm just grabbing a random stack overflow.
Let's let's use Swift actually 2011s still up there in the rankings.
OK running a double double blah blah blah blah blah.
OK.
So interesting.
So you can round a you can use around.
OK that's that's an actual function you can run a swift and you can round something right.
And so my point in showing you this that you could go on to stack overflow is because there's multiple
ways you can do things you can round stuff you can call DOT rounded and all you can do all kinds of
things.
And so my point is there's multiple ways of accomplishing something so let's say you wrote this beautiful
code and it works OK.
And now you've just hired another developer or you're working with a buddy and he comes in and he's
he goes to your wage function and he's like you know what does this seal thing this doesn't make sense.
I don't think that's what we want.
So what he does is he says I think it be better if we use the round function.
OK.
Like so and then we go ahead and pass in price divided by rage.
Let's say he says this because I think this is a much better solution.
And then he commits.
He doesn't even tell you about it.
Right.
Well.
Well let's go ahead and go back to our unit test.
Your bro has just messed with your code and browes never do that.
Dude if your bro is messing with your code he's probably not your bro.
You need to find a new bro because he's not a coat bro.
And let's go to a window shop or tests and what we want to do is run it again and see what happens.
So it broke.
What in the world.
It broke what's going on here.
This is really interesting.
So our unit tests just saved our life so let's go take a look here.
What I want to do is I just want to I want to print this here
see if it will let us or if we have to put it inside a string.
I want to print this here.
Let's see if it will work now.
You wanted in a string that's fine.
No big deal.
We'll use some string Interpol lation like so I would just pass that industry.
So what it does I just put a print statement in there and let's just run the tests and see what happens
so running the tests.
Well we should see a couple of prints.
Okay perfect.
So a 4 and then a 16 is what we got.
But wait a minute wait a minute.
16 but we want to 17.
Our logic called for 17 and we got to 16.
Well it just so happens that the round function if it's point four 9 or lower rounded down if it's point
five or higher it rounds up around it to 17.
Only if it was point five or higher so our bro just broke our logic.
And if you did not have that unit test you might never know you might have published a few versions.
And some people are like hey I think your apps broken because I work 16 hours and it wasn't enough money
to buy the thing you're like.
Well why not.
Because he needed some change.
You never rounded up.
And so you just created a terrible user experience because your bro came in and messed with your code.
But if you had unit tests and if you you're running them every time.
Like we just did you would know that it's broken.
Teske our So what you do with the unit test is you test out the desired result which in our case was
17 the Foresta worked but the 17 did not.
So we knew that we knew that something was wrong right out the gate.
So basically here's the here's the scenario.
Let's say you made 10 changes your bromate 20 changes and you're about to go to version 2 and publishes
the after.
But first you're like I'm going to be a good developer and run all my tests in your run.
And it breaks.
And then you come to find out that your bro messed with your code and now you can make a decision you
could fire the guy or at least yell at them.
Don't buy him any food at least for sure.
And then also you can go in here and you can fix the code.
So that's the value of unit tests.
You run the tests and make sure nothing in your code is because stuff changes especially if you have
like five or 10 developers working on a project.
Things can change.
So luckily we had our test to let us know that it's broken.
You never ever ship with any red Xs.
OK.
So protip never ship code with the red Xs K or never ship code that with failing unit tests because
you know something is wrong.
So now we can go back to our wage and we can put it back the way that it was supposed to be OK.
That's the value of unit tests.
Very very powerful.
So we know our codes are working and we know our test is working.
We know this function is safe to call from anywhere and it'll give us exactly what we want.
So let's go then call this video done that was Unit testing.
Very important stuff.
We just scratched the surface of it.
But you now know enough to start testing other type of model code.
You can't really test controllers with unit tests.
Very very difficult.
OK.
And you don't want to test views but whenever there's pure logic that doesn't require any type of use
like this here math things like that strings anything that you want to do in the business layer and
the business logic write unit tests for everything in the smallest of the test the smaller the the tests
the better the more decoupled your functions are the better.
You don't want function chaining or functions depending on other functions.
So really important stuff.
Watch this video again if you forget any of this stuff.
But that's it for now.
Marc price of slopes.
Come let's go on and forward and finish this at.