In the previous session, we learned about mocks. And stubs are very close to that. While a mock replaces what was there before in order to verify that the dependency gets called correctly, a stub is more a replacement of a specific piece. Let's look at this function.
We want to check how our Pokemon's collection is doing. So first, we want to retrieve what the current size of our collection is by calling a mount function. and afterwards we return a Pokemon save function depending on the size that we have collected actually. If we look at the Pokemon's object, we see we have the amount function and this one should do a call to the database for example.
This is probably the method we want to change. But the save method should actually stay as it is. So we just want to replace or stop the amount method. Let's see how this could work.
First, Let's store the original implementation should we want to access it or restore it at any point. Then let's define a stop amount function that we can leverage whenever needed and this would change the amount outcome. Cool! Next, let's check out how we could use this function in a simple test.
Let's say we have five Pokemons and if we have five we should see this message. We only have a few and we should collect more. So let's write this function and give it a try. To make our example easier, I'll just invoke this function itself, so we can see the outcome on the command line as we did before.
If we want to try different versions of this function, we need to do a short refactor, unless we want to duplicate the whole piece. But we can make it a little better. Let's try. So basically we just...
alter our function, and then we try to call it with different values and see if they match our expected outcome. Perfect. So, we changed the results to what we needed when we needed it. The original amount method is also available if we would need it at any point.
In this particular case, we also saved time by creating a step instead of mocking the entire class. For example, we didn't change anything in the same method. And now we can leverage it and see that our test works as intended. There's only one more term we need to look at before we start using a test runner.
That makes all of what we do so far way more convenient. In the previous session, we learned about mocks. And stubs are very close to that. While a mock replaces what was there before in order to verify that the dependency gets called correctly, a stub is more a replacement of a specific piece.
Let's look at this function. We want to check how our Pokemon's collection is doing. So first, we want to retrieve what the current size of our collection is by calling a mount function. and afterwards we return a Pokemon save function depending on the size that we have collected actually.
If we look at the Pokemon's object, we see we have the amount function and this one should do a call to the database for example. This is probably the method we want to change. But the save method should actually stay as it is. So we just want to replace or stop the amount method.
Let's see how this could work. First, Let's store the original implementation should we want to access it or restore it at any point. Then let's define a stop amount function that we can leverage whenever needed and this would change the amount outcome. Cool!
Next, let's check out how we could use this function in a simple test. Let's say we have five Pokemons and if we have five we should see this message. We only have a few and we should collect more. So let's write this function and give it a try.
To make our example easier, I'll just invoke this function itself, so we can see the outcome on the command line as we did before. If we want to try different versions of this function, we need to do a short refactor, unless we want to duplicate the whole piece. But we can make it a little better. Let's try.
So basically we just... alter our function, and then we try to call it with different values and see if they match our expected outcome. Perfect. So, we changed the results to what we needed when we needed it.
The original amount method is also available if we would need it at any point. In this particular case, we also saved time by creating a step instead of mocking the entire class. For example, we didn't change anything in the same method. And now we can leverage it and see that our test works as intended.
There's only one more term we need to look at before we start using a test runner. That makes all of what we do so far way more convenient.