Welcome back.
Let's continue with our unit tests.
Now, one thing I noticed here is that when looking at the documentation, we actually have an assert
is instance.
So we can actually instead of saying assert true, just use the assert as instance, which we give A
and B, again, all these assert methods, there's no right one, you can use whichever one you want
as a tool to improve your code.
So in my case, let's just change this to assert as instance and fix this.
Like this.
So just a little cleaner.
Let's see if this works.
All right.
Everything is still good.
Okay, let's try and break our code again.
So everything is looking good.
But what if we do something different?
What if we do?
Let's say, add another test and we'll say test.
Do stuff too.
Usually you want to name these functions a lot better, so they're more descriptive.
But in our case, this is fine, just so we can see how they work this time around.
Let's do test ram is going to equal.
How about a none?
So now if I run this, let's run this code again.
And by the way, you might notice here how I'm copying code in a test and you might think, Well, can
we just make this simpler?
And not repeat ourselves.
And you can totally do that and make things a lot easier.
But when it comes to tests, because they don't go into production and this is just for development
purposes, you really want to have tests that are easy to read so that other people understand your
tests.
Because when it comes to testing, readability is really, really important.
We don't care as much about not repeating ourselves and making our code efficient, nice and small.
So I like writing tests that are really descriptive, really obvious.
All right in here, let's say self, dot, assert equal and.
Hmm, what should this be?
Well, in this case, I'm expecting a value error.
So let's do this.
I expect that the result will be a value error.
I'm going to save and run my test.
All right I get an air.
It says this is a type error into argument.
Must be a string.
And I'm giving it a non type.
All right.
So this isn't handling it properly because it just doesn't work with the int we get a type error.
So how can we fix this?
How can we adjust it in case we get a non type in the parameter?
Well, first off, let's give it a default parameter.
Let's say the default parameter is zero.
If I run this.
Again.
I still get the error.
Okay, so we still haven't fixed it.
The argument must be a strict.
A bi like object or a number, not non type.
So we are still not checking for the non type.
So another thing we can do is say.
If number.
So we're checking if we have the number value.
Because remember, this is going to default to true if it has any sort of numbers or well, any value,
but if it's a non type, it's going to turn into false.
So in here, if number we can say return this.
Else.
Otherwise, we'll return.
Please.
Enter number.
So I'm going to say this and now change this because now we should expect please enter number into my
test and I'm going to say assert equal.
That result.
Is going to be.
Please enter number.
If I now run my test, let's clear this.
Oop.
Looks like I'm getting ran two tests in 0 seconds, but we have three tests and that's because.
You see here that I named mine the same.
Remember, if you name the thing the same, well, it's only going to run one of them.
So make sure that all the test names are unique.
So I'm going to run this.
All right.
Ran three tests and everything is working fine.
Very, very cool.
So you can see here how we went from a very simple function and we started catching these errors and
started realizing how our function was too simplistic that if we received a wrong input.
Like.
A string or a non type.
Well, as soon as we did that, our function failed.
So by using tests and as testing and breaking things, I was able to improve this function.
So it's more durable so that now it works a lot better in production.
Right?
And this is the power of tests.
It allows us to check for any mistakes that we may have made because maybe we wouldn't have thought
of doing something like this initially.
But by writing tests alongside our code, we were able to improve the function.
Now, one last thing I want to add.
Let's just add another one over the tests and say that this do stuff for what if the test parameter
is just an empty string?
We should get.
Please enter a number.
So if I ran this.
All right.
Four tests are passing, so it looks like our code is working nicely.
Now to finish off here, I want to just point out a few things.
I'm calling here at Unit Test Main.
But this has nothing to do with the actual.
File.
That we wrote, which is the main file.
If let's say I rename this, so let's go to my desktop.
And say, I want to change this to.
Script, dot pie.
Let's now open this my case with sublime text.
Let's go back here.
So you see here that main pi is well, doesn't exist anymore.
It's asking me to save.
So this is a completely different file.
Now, if I do script here and simply change all the instances to script.
If I save this and now run.
This still works unit test on Main simply says, Hey, just run all the tests over here.
Now one thing, and this is a common practice that we've talked about before is because you want to
say run this file if this is the main file being run, because we don't really want to import test main
or anything like this into other files.
These are individual files that should only be run when we run our tests.
So I can just say if underscore, underscore name.
Equals.
Underscore underscore main.
Then run this piece of code.
So now if I save this and run.
There you go.
Everything is still working.
But now I make sure that this is a test file.
And I'm only going to run this code if it's the file that's being run, if it's the main file being
run.
So this is a standard way that you would have your unit test done with the unit test module.
Let's take a break and talk a little bit more about tests in the next video.