I want to be very honest, spies are the thing that confused me the most when I tried to dive into testing. But nevertheless, in retrospective, I really wished for understanding them as it can be a very, very handy tool. So let me try my best in showcasing you the usage of a spy. Here we have a sessions class.
It uses the last updated one and we can also touch it and again, change the last update value. We see it uses a Date function. As Date is very powerful and the implementation of a mock or stub can be quite extensive, we are looking for another way to verify that the function was called without altering the outcome. Let me show you how a Spy works.
But we will not care for the implementation at this point. We just expect there is a SpyOn function. All we want to do now is let's create a new Spy. So this is a very common pattern you would see when working with libraries that enable spying.
We take the main object that we look for, and then we can assign the method that we want to spy on. So this means now, if we would call DateNow, I can later ask the DateSpy if it was called. This could look something like this. In this case, DateNow would still work as before.
but we can verify that it was also called correctly. Many implementations that are available for spies allow for direct alter of return values. For example, you could do something like this. So as we now know all of those important tools upfront, we will have a way easier job in dissecting functions in the testable code if needed.
If we now look at test runners, We have a better understanding of their capabilities and what all their examples actually want us to do. And we can really focus on using the tools to achieve what we actually want. I want to be very honest, spies are the thing that confused me the most when I tried to dive into testing. But nevertheless, in retrospective, I really wished for understanding them as it can be a very, very handy tool.
So let me try my best in showcasing you the usage of a spy. Here we have a sessions class. It uses the last updated one and we can also touch it and again, change the last update value. We see it uses a Date function.
As Date is very powerful and the implementation of a mock or stub can be quite extensive, we are looking for another way to verify that the function was called without altering the outcome. Let me show you how a Spy works. But we will not care for the implementation at this point. We just expect there is a SpyOn function.
All we want to do now is let's create a new Spy. So this is a very common pattern you would see when working with libraries that enable spying. We take the main object that we look for, and then we can assign the method that we want to spy on. So this means now, if we would call DateNow, I can later ask the DateSpy if it was called.
This could look something like this. In this case, DateNow would still work as before. but we can verify that it was also called correctly. Many implementations that are available for spies allow for direct alter of return values.
For example, you could do something like this. So as we now know all of those important tools upfront, we will have a way easier job in dissecting functions in the testable code if needed. If we now look at test runners, We have a better understanding of their capabilities and what all their examples actually want us to do. And we can really focus on using the tools to achieve what we actually want.