 Okay, I am going to start to explain about using mocking in testing. This is about dancing with shadows, about stab, mocks and patch. Okay, we are going to explain why we need to use mockers, after that how to use patch to use our mockers in our testing. We took a kind of simulator, stab and mocks and libraries, some libraries used specifically for mocking in web development. Why testing? Why using automated testing and how to use fakers? Normally you know when you start to program in that code doesn't work when you type it because you need to test it even manually. But when you see your system grow and the complexity grows, you need to put this automatically because you need to ensure that every part of your code is tested. So there are two possible types of testing. One is integration test that tries to test a whole feature in your system. And after there are unit tests that just try to test specific functions. Okay, testing are used in both cases, mocking are used in both cases. One case is when you want to isolate one part of your code to just test this piece of code. Trying to mocking all the classes or objects that are outside this. Other case is when you want to try to test a feature but you don't have the special hardware or the special API that you need to test this. Because you need sometimes something that is very expensive or is in development or you don't have all the day access to this. Or you don't want to use this in every case you need to use automated testing. So one important case to use mocking is in input output operation that they are usually closely. And when you have something probably events I think about for example when you want to test input output in a file system and you want to test if how your system works when the file system is full. You are not going to full hard disk just to try this. You want some way to simulate this kind of event. Okay, you can use mockers or fake objects to simulate functions, classes, objects or even complete libraries. They should be predictable so every time you run the test it should give you the same output repeatable fast. Because when you have a test that takes too much time you tend to avoid using them every time and the usability of the test they need to be lightweight and cheap. Okay, on patching, what is patching? Patching is when you try to use this fake object instead the real one and you put this on your test. I am going to talk about some common errors in patching the scope, some trade-offs and how to avoid some of these trade-offs and have another using inverse dependency. You need to be clear about which object are you going to patch. You need to patch the imported one into the namespace you are going to patch and not the original object. When this very short example this is going to be more clear. When we use B.py we have B.py and we use in one case in the left I have from A import class. And then you need to know that in the module B.py in the namespace of this model you have B. You have class, you have the name class and then you need to patch in B.class because you have to patch this namespace, the namespace of the B module. In the right you have import A. In this case you need to patch the A.class because you are going to patch the namespace of the A module that is where you are using the class object. You can use different scopes in the patching operation. You can use decorators, decorators are when you use the art sign and you can stack many decorators and the decorators are injected as arguments inside the testing function. In this case you can see that the upper most are in the right side and the down are in the left side as you see in the color, the green and orange colors. You can also use a patch with context managers. Context managers are when you try this with patch, use a mock. The mock is automatically created. A mock object is automatically created in this class and I am going to explain after this about mock object, the properties of mock object. You can see, you can see, you can change the mock object, etc. After all you can use also patch and start and end this. Patch changes your code at running time so you need to use wisely, sparsely. You don't have to use a lot of patch, just the one you need. So, you can use class decorators to patch objects, you can use function decorators to patch objects. You can use context managers and then the patch is going to work just inside the context manager and you can manual start and stop this. There are some trade-offs when you patch. One of the things is that you are going to have your test co-plat, strongly co-plat with the module you are going to test. Because you need to go with all the paths and see where you are going to patch this specific option in this specific space, name space. So, one thing is that you are going to need to maintain this. Another thing is that patching changes behavior during run time. Of course, this is why we use fake objects, this is why we use simulation because you need to change. But always when you change the behavior in your run time, you need to be very aware of how you are doing this. And they can be sometimes complex and expensive because sometimes you need to try to find the real path to put this patch. One thing you can use instead of patching is using dependency injections. When you use dependency injection, you just inject object classes needed by a piece of code as an argument. So you can use direct replacement. In this very little sample, we have a stop method that just returns for as less in the anima. So, when we use the dependency injection, we put the class animal as an argument in the creation of the instance instead of using inheritance. So, when you use inheritance as in left, we have a strongly coupled the parent class with the inherited class. And when we use the class as an argument, we can see that we just can pass the class that we are going to use. The method as an argument. So, it's easier when you need to replace using just in the implementation time using stop animal and that's all. So, you have a stop animal and then you can return for left and that's all. This has also some trade off because you need to change your code to use injection dependency. Injection dependency is a practice that gives you more flexibility and has another advantage outside testing. Okay. I am going to explain about mocks. Mocks are a special kind of object that Python give us in the standard library. We have mocks and magic mocks. Magic mocks have many of the magic attributes, magic method implemented. So, you can say in magic mocks, for example, the length and they are going to return zero when you want to see, for example, the value and they will return a true, for example, mocks can be customized. So, they act more like the real object. For example, you can change the return value. You have just the attribute to mock the object. You say return value and when you call the mock, the mock will going to return the desired value that you put in the attribute. You can also use side effect, which is more flexible. Inside effect, you can put a list of value so they are consumed every time the mock is called. For example, we see here 5, 4, the list 5, 4, 3 and every time the mock is called, it returns a new item inside the list. Using side effect, you can also return an exception from the mock. For example, if you need to prove an exception case. One limitation that it has is one special case. Mocks, when you call a property in a mock and the mock doesn't have the property setter or the attribute setter, you will see that it will create the attribute in runtime. So, for example, if you want to create the animal attribute, you will see that it is going to be created. But what if you make one type or one little mistake in the name of the attribute inside the function or the piece of code that you are going to test? In this case, mocks give you a false sense of security because you are going to use an attribute that is created in real time. But in the real world, when you use the real object, a real object doesn't create attributes as them and when you need it. So, to avoid this limitation, you can use specs. You can use the real object, the real classes and you can use them as templates to your mocks. So, the mocks have the list of attributes and limit it to this. So, specs here are going to see, expect copy attributes from a real class to a mock and will give you an error and say you, if you are accessing an attribute that doesn't exist previously. You use this using the create autospec function. Create autospec gives you the template from a function. For example, here you have a function that has three arguments, APC. Three arguments to use this and when you create the autospec, you can see that when you use the mocks, everything is going to be fine. When you use the real, the correct number and type of attribute of arguments. But when you give wrong arguments to the function, you are going to see that it's going to give you an error. So, this helps to ensure that testing tests correctly and give an error when it has to. Okay, mocking has another use when you want just to wrap a real class object, a real object in your code. For example, sometimes you want to call the real object. But you say, if I call the real object, why I will use a mock? Because in this case, mocks is going to help you to record every call to the function. Mocks also act like a recording object. Every time you call a mock, the mock creates a structure that you can use in your testing to make assertions. Assert call it, for example, and you can use it to see when it was called. Assert call it once if it was called just one time or it was never called. You can also see about how you can also test the arguments of the calling in the call function. For example, if it was called in a specific way, it was called just one time with a specific set of arguments. If it will have any call with this specific argument or if it has some call with this specific set of arguments. You can even see the list of all the arguments as a property of the mock. Finally, I am going to explain two special libraries that we use to test the use of APIs in web development. First, I am going to talk about VCR. VCR is a library that helps you to record in a special file called cassettes. Every interaction with an external API that your system has. For example, you have two times in this VCR library. One is when you have the saving. The saving time is when you record the interaction and you have to use it with VCR record arguments. You run your test and you are using PyTest for example. VCR has a plugin to PyTest and you run your test using an argument called VCR record. VCR record once or VCR record all. After that, you have a set of special text files that give you all the interactions. You can use it to test if your code asks for the same request and it gives your code the same responses. You have all the interactions, the request and the response and after the request and the response. If the request was the same, you can say which attribute to test, the URL, the argument and even the payload. And then it gives you the response and everything. Using this special library, you avoid to use an API because using an external API has a lot of trouble. Because sometimes the external system can be down, sometimes it can be expensive, sometimes it can be very slow. So you don't use, it's not as bad to be dependent in every automation test to use an external API. And finally, we have about MOTO. MOTO is when you want to test using the BOTO AWS Amazon Web Services BOTO library. BOTO library is used to access all the services from Amazon. Sometimes, as you know, Amazon Cloud Service can be expensive and you don't want to change things in your real cloud service. So you can use just as a decorator in the test function and it will change the real call in the tested object with MOTO calls that are especially tailored to be like BOTO services. Okay, so finally, why we use smokers? We use smokers because sometimes it's difficult or it's expensive or it's very slow or something like that. Using external APIs or external object or hardware object. Or sometimes we can use smokers also to just isolate, just use test some part of our code isolated from the rest of the system. How we use patch? We can use patch using context, manager, decorators or manually starting and stopping them. And we have to be very aware of when we are going to start the patch and when we are going to stop. We need to remember that it is a change in the real time, in the real run of the code. We can use dependency injection, if we use dependency injection we can avoid using patch. There are two kinds of simulators, one kind of simulators are stopped that are just simplified objects that we use only for testing. And mocks that are special objects that the standard library gives us and have a lot of interesting characteristics features. And finally I explain briefly about two libraries that are external that are not in the standard library you need to install from Pi Pi for example. Just VCR and Moto. That's all, thank you. You can follow me in LinkedIn, Twitter or as Marianne now in GitHub. Thank you. Do we have any questions for Maria? Thank you so much Maria for a brilliant talk. That was lovely. So do we have any questions from the room? All right, do we have any questions? Oh, there's a question. Thanks for the talk. I have one question related with the APIs and how we can create a class that can be mocked and patch an API class that performs like an interface to don't use a real API. And if there is a standard way to create a class that mocks those kind of classes. Okay, let me explain again the question. Is there a standard way to create a class that patches a real class using mock methods and using the assertions that those methods let you... Okay, if you use an external API, probably are you using requests, response and everything like that. So if you use an external API, I think it's a web API. If you use a web API, I suggest you to use VCR because it works very well. I don't know if you are using a web API or another kind of system. Yes, it's a web API. And about the VCR records, I have another question. And how can we save those records and reuse it in, say, AICD? Okay, I am going to explain a little more about this. You have to install VCR if you use PyTest VCR. And after that, when you run your test in the first time, you can disable VCR in this case. You use the real API or you can record in the VCR every interaction. So when you test your system, because in the test you call a function in the system, it creates a request. It records the request and records the response in a special YAML text file that is inside a cassette folder. Do you understand? So we have in the cassette folder many different text files in YAML format that record every interaction, every request your system does and every response your system gets. Okay, perfect. After that, you just say the PyTest to run normally. And in this case, the decorator test with the app VCR decorator are going to use the YAML as the source of truth. Of course, of the real information that came from the external system. Okay, they are using this information that was recorded in the first time as the source of that. So this has one little trade-off because sometimes you need to record again the test. Hey Maria, we're right on the time right now and we have to break for coffee. But maybe if it works, then the person who has the question can maybe reach out to you via Twitter or LinkedIn if that works. And you can maybe explain that. Okay, of course. Don't worry. I have telegram also and telegram. Awesome. I use the same. Awesome. Thank you so much for your time. Thank you so much for your time. This was lovely, lovely. Thank you so much. Thank you.