Welcome back.
Let's do a fun little exercise by revisiting a piece of code that we've written before.
Remember the random number guessing game where we have to guess a number between one and ten?
If I run this file, you see that?
It asked me to guess.
So let's say one, two, three, four, five, six, seven, eight, nine.
And I finally get the number.
You are a genius.
The number was nine.
So how can we test this code?
Now, one thing you'll notice here is that we don't really have a function.
And remember when I told you about functional programming and how it's good to break up our code into
small bits of functions that do one thing and one thing really well, especially pure functions.
Well, one of the big benefits with that mentality is that you create code that is really, really easy
to test.
Instead of having really complicated logic in our tests, we can simply give our functions an input
and expect an output.
And this is why we have unit test.
And the idea of a unit test is that we're testing each piece of unit.
These unit tests are small little pieces testing these simple functions.
So my challenge to you is to use this code and try to break this up into simple functions.
Now.
In our case, I want us to just test this part of the code, which is the guessing part, where we receive
an input.
Which will be the guess and then test it against some random answer that we have and we should expect
some sort of output.
So either we enter a number.
Has to be 1 to 10.
And if we get it right, we have to get the string.
But the key here is that we probably want to move this into a function that we can test.
We can ignore the outside world.
And break this up into its own little function.
So pause the video here and give it a go.
You're going to have to get through some stumbling blocks, but it's going to really test your understanding
of tests.
Ha ha.
Funny.
That was a pun.
So pause the video, give it a go.
Otherwise, I'm going to get going with the answer.
The first thing I want to do is to set up my test again.
I'm going to import unit test and I'm going to create the class test main.
Or let's call it test script this time or a test game.
I'm going to say unit test.
Test case.
This is going to be our test case.
And then here I'll create, let's say, just a simple test, let's say.
Game or test input.
Receive the self.
And for now, I'm just going to pass this because we're not really doing anything.
Finally, I'll say if.
Name because two main then run the unit test.
Dot main.
So this is just our simple setup.
So if we run this now, let's say Python three.
Test pi.
We see that we ran one test.
All right.
So this is our setup.
Next, what I want to do is actually take this out so I can use it in my test file by extracting it
into a function.
So I'm just going to say at the top over here.
I'm going to define our guess.
Game or let's call it run.
Guess.
That's going to receive a input.
Or let's say a guess, and then it's going to run this code.
So let's do that.
I'm going to take.
This piece of code.
Like this.
And simply paste it in here.
Now the wrong guess is also going to need the answer variable.
So I'm going to give it a second parameter answer.
Like this.
So that now I can just simply inside of here.
Run this function with the guess and answer.
Just like that.
So let's save it here and run this test, or let's just run the actual file to make sure that it's still
working.
Oh, and we get a bit of an indentation there.
So we have to make sure that our indentation is correct.
Because remember in Python, that means something.
All right.
Now we have an issue.
We have a break outside of loop because while we're using the break key word and well, we're outside
of a loop right now.
So one thing we can do is we can say return here.
So let's run that again.
And keep guessing a name.
Or a number.
And there you go.
This is still working.
I'm able to use return here because this well is going to run and return.
But now we're still inside of the game.
So maybe we can just return.
True.
And say if.
Run guess.
It's true.
We're going to break out of this.
Again.
Let's start our game.
I'm going to just clear this and run the game again.
One, two, three, four.
And there you go.
I've entered a number.
I'm a genius.
We've just finished the game.
Let's make this a little bit smaller just so you can see.
So we have our run.
Guess I've modified the code a bit.
But the key thing is that I've extracted out a unit of functionality so that I can test something like
Run.
Guess.
So it looks like I have modified our code, but the code is still working.
So now let's start testing our run guess function.
Let's go here.
And start importing our script.
And in here do a few things.
First, I want the answer to, let's say, equal five.
And the guess is going to equal five.
So we want to make sure that if the guess and the answer match that, well, the wrong guest goes through
the if statement and prints out you are a genius or a non case returns true.
So let's say self dot assert.
Equal.
That script or actually first time around let's actually run it.
So let's have result equals to script dot.
What was it?
Run, guess.
Run.
Guess.
And give it the answer.
And guess.
And we expect the result to.
Return.
True.
So we can just say assert true that.
The result is true.
If I now run this.
Oh, we actually start up the game.
So how can we fix this?
Well, we can close this and actually add the if name Main.
In here.
So down here.
We'll say, hey, only run this if this is the main file being run just like that.
If I go back to test here and run this again.
All right.
Now it's working but I get an assertion error test game object has no attribute assert true because.
Well I.
Misspell that.
Let's try that again.
All right.
It looks like one test ran and everything is good.
We also see that it printed out.
You are a genius.
Very, very nice.
By the way, I'm showing you this way of testing because this is how a real life scenario looks.
You keep breaking things, you keep making mistakes, and then you try and fix them and correct your
code.
And you can see our code is already looking better and better just by running these tests.
Okay.
What else can we do?
Let's say here.
That we're going to copy this.
And just so things are shorter, I'm just going to directly enter the parameters in here.
Just like that.
Let's say input, let's say incorrect.
Or.
Wrong guess.
So let's say the answer is five and I guess zero.
So we want to assert that this is going to equal false.
So if I run this.
To test their passing.
That's awesome.
What else can we test here?
All right.
Well, we want to test that if the guess is not between zero and ten or between one and ten.
In that case, we want to have a print of.
Hey, Bozo.
I said 1 to 10.
So once again, I can test.
That if my guess wrong.
Number.
Let's say the answer is five, but I give 11.
We want to assert.
Well, right now we're printing and not doing anything.
So maybe we should return false just to have some consistency here.
Again if I do that and I run.
There you go.
Three tests are passing.
That's great.
And there's many, many more tests that we can write.
Maybe let's do one more test, which is to test.
What if the input is a string?
If I run this.
Oh.
And make sure that wrong.
Type here.
Make sure the names are different.
And I have four tests running.
Because this isn't going to pass and it's going to return false.
Now there's many more things that we can do here.
But you can see the power of test right now.
If you have different tests than me, that's okay, everybody.
Test cases are different.
The whole point of testing is to just simply.
Look at our code and see how we can improve it, how we can break our code, how we can simplify our
code by breaking it into smaller units, smaller units that can be tested and fix some errors that perhaps
we want to have thought about.
Now there's many more things that we can do, but you'll notice here how the idea was to work on small
piece at a time.
Test it, and then maybe further on we can look at this part of the code or maybe the try and accept
part of the code.
And here's the thing.
When you're working for a company, I argue that there are an infinite number of tests that you can
do.
You can have hundreds of lines here to test your code to bits.
But just because you're testing as many times as possible, it doesn't really make your tests good.
Like I said, there's an infinite number of tests that you can write.
The idea is to write to good quality tests that cover most of your cases.
But eventually you'll have diminishing returns where you have to have a trade off between writing code
and writing tests.
And sometimes, depending on what the job requires, you might have to focus more on tests and focus
less on code.
Or sometimes maybe you need to move fast and you don't have time to write tests.
And again, depending on the business needs, that might be the case too.
But with this section, I hope you understand some of the principles following testing in software development.
That is, bugs are always going to arise in our code.
And we can use lighting to help us with this.
But one of the best ways to make sure that our code is working properly is test.
And the more tests that we have usually means the more stable our code.
I'll see you in the next one.
Bye bye.