Django and Wiremock: End-to-end tests made easy

Speaker 1: But on stage now I have Romulou.

Speaker 2: Thanks.

Speaker 1: Welcome and uh super exciting talk that you have for us. Um I think so already. I've been looking forward to hearing more about wiremocking and how to do that with Yanko Um so give Romulo a warm hand.

Speaker 2: Okay, so let's start that you have found your dream child. Now we are responsible for managing Minecraft customized servers. So you can you dispose some servers over the internet and your friends can now connect to the Minecraft and the play. And maybe this Minecraft service has some difference. Maybe the creeper does not explode, but it gives you code, diamonds. Yeah. It's because we want to not play with the vanilla Minecraft. And um yeah, and uh as the maintainer, as the manager of the Minecraft service, you have some uh tasks, you need to do some some things. One of them is play Minecraft all day long. You need to monitor the service, get get some health status, and

Speaker 2: maybe you need to turn um turn off the the the servers and uh one of the tasks is maybe some uh send some message to the to the place some broadcast uh broadcast messages Yeah, but you need to manage several uh servers and uh that's not nice. You need to think you need a tool that's gonna simplify your life. So a software that you can keep control of of the service, no understand what's going on, and uh and I need a solution that you are capable to make in uh RPC and also to get a nice front end because you want to to have uh need to to to administrate and I need interface to administrate and another in the other end you need something to talk to the Minecraft servers. And uh you need support for accounts.

Speaker 2: uh users maybe you are not managed the service alone you need some friends and uh you divided the work you are responsible for half of the server service and the another your friend is responsible for the another one And uh yeah, and you need to get the job done without first, without hassle. You just need to get this tool out of uh out of the blue and uh play with it right away. So you decide to go for Django. Django, you can get the job done, and uh you can manage the Minecraft service. So you have you are on the side, you talk to the Django, and the Django talk uh talks on your behalf to the Minecraft service and you send commands. to the jungle you get some response back from the Minecraft service yeah everybody's happy your boss is happy

Speaker 2: because now you can do more You now can focus on different problems. You don't need only to do an SSH in the machines. The community is also really happy because you can manage better the servers. But the product guys are not never happy. They are always asking for changes. They are uh asking for new features. And also as engineers we would like to move ourselves to uh to the next level. So maybe we want to move our way from uh synchronous calls to asynchronous calls, or maybe introduce an aq, who knows. And uh, you need to hand over the software, the system to the most evil person in the world, which is yourself in the future.

Speaker 2: You know, I bet you guys have that feeling. Oh, who wrote this code? Ah, that was me. Yeah. That's a bit of a shame. So you need to think in a way to to manage the these complex scenarios of threats, constant changes, because the only constant in the software industry is things are gonna change. Yeah, that's why I'm here today to talk about a little bit about Django and WireMock and why it's important to make end-to-end uh tests and uh how uh how come that it can be easy I'm Romulo. I'm from Brazil, particularly for this part of Brazil, northwest part of Brazil. And uh yeah, in the front of the city of Recife with with nice beaches and uh

Speaker 2: is a tropical uh city But um I'm living here in the market since 2017. So far so good. I'm happy to be here. And uh I got more than 15 years in experience in the software industry. I have to play with Java, Go, C, JavaScript, a lot of technology, a lot of languages. And today I'm software senior engineer at Matter. It's a fintech, a nice fintech. And I really love what I do. I wake up every morning, take my bike, go to the work, and let's see what I can achieve today. So with the experience, yeah, that happens with the experience I have seen a lot of problems, a lot of bad things I have introduced a lot of uh uh

Speaker 2: shit in production. My last one was to to tear down the the the Kubernetes cluster of the company. But that wasn't nice. But with the experience I now also have seen a lot of tools, techniques, and the process. Python, I've been played with Python since 2006. Yep, and it's a nice language. You focus on the problem, you get you get your job done. Django since 2009. Yes, and uh I'm I'm from the age that even Django uh wasn't capable to uh to support multiple databases. Yeah, that that was uh uh really nice appeared. And uh I love jungle because I can set up something really fast and get the job done. And uh pair programming, I really like

Speaker 2: I really appreciate pair programming. I would love to do more of it. And uh it is something that when you have someone to talk, when you have someone to share ideas , things happen you know the the synergy effect with when one one plus one is equal to three and uh yeah it's that that's amazing uh I do recommend you guys to do more pair programming but My focus today is about talking about this this uh process, this this technique, which is test-driven development. And uh, in my opinion, it's not only uh about writing the uh the tests first. It's not only about it. So what is TDD about in in my opinion? Is to make tests simple, is to make your application testable. If you if it is hard to test your application, then you need to

Speaker 2: Let's let's think uh uh more and uh let's let's make it happen. Is to embrace change, is to you no longer be afraid, afraid for uh introducing new features or to do some refactors. Let's make it new new stuff without without fear. Is to facilitate refactoring. If it is hard to to replace some part of your code with another one, then Try try to to rethink and try to introduce a test so you can simplify your life And also it's about to push more design think to the code. When you need to to to make your application testable, then you need to step back. Okay, I need I need I need to figure out how I'm gonna uh uh uh Interact with the functions or how I'm going to interact with the

Speaker 2: interfaces easily. Yeah. And also it's a matter of making the quality as a team effort. It's not only one department that should take care of it, like the QAs. is the whole organization. You as engineer, you are the first one to get in touch with the code. You are the first one to get in touch with the the project, the project, the product. And then you you should start to think the quality from the beginning. Yeah, and I really appreciate this quote from JK Kepler Moss that a code without test is broken by design. Thinking that I like to think tests as a formal specification of your software. You are not gonna get in a software or

Speaker 2: project without bugs with tests, but you are gonna get some sort of process, some sort of code or documentation that is gonna make sure that your software do does what it's supposed to do Yes, and uh I like to think tests as real users. Uh they are the f uh if you think that Who is gonna use this function? Okay, the first one is gonna be my test. So I need to think, hey, I need to make the the life of the test easier. Because at the end, when you are developing something, you are thinking we make the your users. to get something done to to be more happy to be to to be easy. So think also tests as real users. And then then the I bet that the quality of your project is gonna

Speaker 2: grow. So let's go back to our to our problem to the beginning. You have created your Minecraft server. To administrate uh uh uh you have created spawn minecraft service and you have to create this administration uh tool Then after you are logging on the on the system, you get the list of the servers that you are responsible of. The green one means that the server is live. And the red one means that the server is offline. That's a first indication that maybe something is not nice on the on the field. And um You decide to go into the server one and uh that's the the screen that that you get. Uh again the the status of the the the server, some some metrics about the the the the the the

Speaker 2: Some the CPU, the uptime, and uh and uh you get also a field, a form where you can broadcast messages to the to the to the players And uh you write something on the on the field, on the form, and then you press the button send, you dispatch the message to the to the jungle, and you get back this uh alert, this this message that everything went fine. And on the Minecraft side, you'll see the message. The users can see the message. Yeah. Pretty simple user case. But uh uh yes, and um under the hood, uh this is uh the Django model

Speaker 2: is uh bear with me This is the first iteration. This is a very simplification. I know that there are a lot of opportunities to improvements, but our focus is to get the job done. And yeah. So that's that's the first iteration. And you have the model a name, you have the address, and here is the method that you actually uh make the the you send the message to the to the Minecraft I'm using the request library. This is the end point. You have the headers, some for some credentials, the payload. And uh if something uh goes bad, if you uh the requests uh throw an exception, I return false, and uh if If there is no exception, then I verify the status quo for 200. And uh why two

Speaker 2: hundred? Because that's what the documentation of the the the this endpoint says that if you get back at 200 I got your message and that now it's my responsibility to deliver to the to the clients and uh as part of my contract I return a boolean That says true, uh, the message has been sent, false. Yeah, something went wrong. And uh you would like to uh oh by the way, this is the view. Uh when you call the the the for the browser and um yeah again bear with me a simplification just to get the job done And uh you get you get the you get an object from the database, and uh you verify the payload if the payload is in

Speaker 2: right format And uh and I use the method that I create to dispatch the message, the message, and I pay attention that now I'm switching to a 204 because I I don't want to send any message back to the to the to the sender of the the the the message. I just want to say hey everything went fine. If not, then I return uh uh an error or a 502 case I'm not able to send the message Yeah, for simple enough, I I made this uh view to be login required only. Uh login users can send messages Pretty simple, get the job done and up yep. So the first approach to assure the quality of the the of your application is to create a unit test.

Speaker 2: Unit tests you can mock uh the objects, you can maybe use techniques like dependence injection, you can maybe uh inversion of control. And uh you they are meant to be simple. And uh I do think that is Uh it's okay to use that handyful database in memory that Django provides for you. So test case, no, no, uh don't don't reinvent the the real. So for my model, I've created this uh this unit test Uh look that I'm mocking the the I get the request the request library mocket and then I'm uh pretend what uh

Speaker 2: what what's gonna be my my uh expected response and i also attest that the my library is getting the is getting the the the expected format to send to the to the to the to the minecraft server And then yeah, and finally I make sure that uh with this uh this configuration I can send the message. A big deal, I guess. And also for the the view is pretty similar, but instead of mocking the HTTP the request library, now I'm mocking the object. uh that I get back from the database and uh also uh uh mocking the the the send broadcast broadcast message from the model.

Speaker 2: And uh again verifying that I'm gonna send a response back at 204. So pretty simple you need to test And um yeah, then you start to make questions. What if I want to refactor that for an asynchronous code? What what's gonna be the amount of effort to to to to to implement uh a sync. And what if I don't want to mock the HTTP library? Because you are entering on implementation details when you mock things. That's not nice. And what if I want to make a real HTTP call? And what if I want to be able to test fully my my fully entered my my my server uh from from local then you need an a real http call you need to call the

Speaker 2: the the server there is there is no magic you need you need to call What are the challenges when you start to play with real servers? The first one, network is terrible for tests. You don't have control of the network. The internet is a wild environment. You can package drops, bad things happen. The internet , the internet connection may be slow. It's terrible. How about secrets? When you are talking to different servers to third parties APIs, you usually need to provide some credentials. It's not nice, terrible idea the idea to commit secrets on your code. Of okay, maybe GitHub, GitHub or CICDs offer options where you can configure the secrets and you can reuse it.

Speaker 2: But usually the people that is responsible to manage the secrets, to manage the accounts or to rotate the accounts is not the same people that is responsible to manage the CICD. And then it's it's more and more more complication to to run the tests and to configure them And also uh infrastructure configuration. Maybe you are running in an CI-cd environment that you are not allowed to go to uh out of the internet. I don't know what what kind of setup do you have it. So yeah, that's not not an option. Uh DDOS tests are that tests are supposed to be fast, so and uh you need to test several scenarios and uh Which means you are gonna make a bunch of requests in a very short period of time.

Speaker 2: And maybe the the firewall of the 3DP API can think, oh, I'm under attack. I can see this amount of requests in this short period of time. Maybe I'm under attack. Then I'm gonna start to block you for this period uh for a period of moment. And then your colleague cannot get the the job done because now you have provoked block to access the to the pad API Also, about test configuration for our example, we are running uh Minecraft servers. You can download the jar, you can set up the environment, but come on guys. We are supposed to focus on our application. If you need to run uh this big setup, then we we uh uh we need to uh go to a different kind of tests

Speaker 2: And uh we should keep focused on the quality of our partner that we are responsible And uh also it is really hard to simulate and to get uh uh server-side fails. It's almost impossible to provoke in a 500 uh or uh you want to simulate uh uh retries you want to simulate uh uh if they send garbage to me yeah that's not nice and uh That means that we need a different kind of tool to provide uh uh the solution. And uh I do recommend BireMock for for it. What is a WireMock? It's this big word. This is what uh you can read from from their website. It's an uh HTTP-based API

Speaker 2: that You can mock in HTTP-based APIs. What I like to think in this way, it's a tool that places only the necessary infrastructure to fake real HTTP APIs. Just it. Just what we need. What we need, you need to be able to talk to a server through HTTP and get based on some response, get something back. Yeah. And I've been using it for more than five years in any kind of in very different projects in Java projects, Scala project, Python projects, and it is It 's good and it works and gets the job done. So, talking more about wiring box. As I said It's uh you get back HTP

Speaker 2: response based on some match criteria. Those match criteria can be uh uh uh aga Brigasp can be on a particular header, can be in a particular content type, can be a request, HTTP request that you usually send to the to the API. Um you can uh template the responses based on the requests, which means that if you send it, for example, an argument on the request, you can move the that argument back to the to the body to the response and uh for example if you are creating a user and you can fake that you send the username and then you are gonna see back you are gonna get back the username Maybe your code requires this kind of uh behavior. You can simulate faults, you can introduce delays, you can return 500s, you can return

Speaker 2: uh uh uh uh uh 504 you can return garbage you can return you can drop the connection you can simulate uh uh faults that is really hard to get when you are playing with real servers And what if you want to get in a test? What if you want to test the retries mechanism that we usually have in our code? For example, the first attempt you get an 500, and then you wait a little bit, then you test again, then you get a 200. Just to test your uh retry mechanism or your circuit breaks, you can you can simulate them with stateful behaviors. You can verify the requests again. Yeah, sometimes you need to check that you made that proper request without mocking it.

Speaker 2: And uh you can record and play back. You can put wire mock between your server and at the your your server, you can record the request, save the the the the the the request that you made, save the response that that that you get uh that that you get get got back and then reuse them for tests to re implement tests. Yeah I think that's a really nice feature uh uh to to to have Uh in order to get it run, yeah, it is in a Java application. You download the jar and I run as this one. I don't know which kind of Environment you have in your machines, Windows, Linux, Macs, I don't know, but yeah, this just works in any kind of environment. Or maybe you can get it as an um Docker container. Simple like that.

Speaker 2: And how do you mock the requests? There is this very special uh endpoint in the wire mock. It's a web server, you start. And you get uh uh uh uh URL back, then you gonna make in a post to this endpoint. You specify what kind of request you are gonna make And then you specify what kind of response sorry you specify what kind of request you're gonna make, and then you specify what kind of response you are gonna get back. Uh and can be a JSON, can be uh XML, can be uh HML, can be any any any valid HTTP response You specify as a JSON, but

Speaker 2: you can get any kind of uh uh HTTP valid uh structure. Yep. How do you verify? Uh if you are in the Java world, then uh there are more tools to verify to make sure that what kind of requests you made, but Since you are on the Python, then you can use this endpoint request counted, and then you can verify that okay, based on this request that I made, I can see how many times that has been counted. How has been requested. Yeah. So our first first refactor using wire mock uh is our view. I'm now going to make in a real uh I'm gonna mock the the the the the end

Speaker 2: point the the to uh send broadcast messages and then now I'm gonna just test that I'm getting the response back as I as I as as as I expect less code direct to to the point. Um and uh you are exercising the uh very Many parts of your code, simple. And uh you are not playing with your real server, and uh yeah, it just like this. And uh, this is the way that I do uh with my my projects. I mock the the response and I uh call the the endpoint. And uh here maybe you can call direct with the the method instead of calling the view.

Speaker 2: You decide. What's happening here? You are running your test inside of the Django application, and uh the Django and the test thinks that they are talking to the Minecraft selves, the database is there to exemplify that is a complete uh solution. But in reality, you are not talking to Minecraft cells, you are talking to uh wire mock. But pay attention to this line. What kind of information I'm getting here is I'm dependent on the Django framework to set up the environment for me. Uh or maybe I can uh not not touch some parts of the code that I know that's problematic and yeah. So that you are inside of the Django

Speaker 2: context. But your users, your real users, don't care that you are running in Django. They don't care. They don't just want to use your uh interface. For for so you need to go up on the abstraction layer. You need to move out from the jungle. And then is when the end-to-end test starts to make sense. They are agnostic to servers framework. Uh they speak the language of the the the interface. And they are pretty similar to integration tests, and but you are only allowed to use the public interface. You are not allowed to use the backdoors that implemented Because your real users uh they are not aware of of them and uh

Speaker 2: and you want to test the your your solution from end to end entirely Um and uh you run, you start your server as production, but using the test configuration. Yeah, you're not gonna hit the real production. Uh the real uh 30 pad API. You are gonna read the Minecraft the the wire mock server. Um and uh the data should live only during the execution of the test. You spin up Your server, you run the migrations, you if your migration includes some scripting, then you execute it. But after you tear down, then the data should be gone. You should not reuse the the previous uh test. And this is the kind of test that I like to think that they survive a major internal refactory.

Speaker 2: If you decide to update the your Django library from three to four. Your end to end test should not be affected by this uh this refactor. If you decide to move away from Django to, for example, Fast API, if you are running uh uh RESTful uh uh uh uh interfaces then they should not be affected by the those those uh uh those refactors And uh yeah, how does it look? Uh your test is pretty similar to the to the test that you implement for the view But now I'm gonna use the request, the library request, and I'm gonna use the session. I log in, get the credential, put put in the session, the cookies. mock my my object and then I test again um uh my my endpoint

Speaker 2: and be aware that here I'm not talking to jungle there is no reference to the jungle here at all Um yeah, now from the top level, your end-to-end test now is gonna hit your application as a black box. You are not aware, but the external parts. It should be aware, right? You are testing your application, you are not testing the full environment. Now it's a black box. Again, you have in a database, a live database, and that your application thinks is talking to Minecraft. But in reality is using wire mock. And uh what if you don't have tests at all in an application? That happens, time times that happens. So I do recommend you start creating tests. A RIREMOK is great for this case

Speaker 2: because as I said, you record and the playback, you save the the request that you are making to the third party. And uh and uh yeah, and I and reuse the that information that you have saved and to to load the wire mock again. Don't do it programmatically. That's that's a lot of work to do. Yeah, and then this is the the the the pyramid that the the test pyramid I think that uh you guys are aware of it And uh you should focus in have more unity tests and service tests than UI or end -to-end tests because those kind of tests are very expensive and very slow to run Yep. And um if you want to debug, it's pre pre

Speaker 2: I I if you have a problem in production, I like to debug using end-to-end test. What I do is I reuse the the very same setup. I start my dependencies manually. I I'm not gonna start altogether. And um then I start my Django application in debuggy mode, maybe in on from your IDE But uh is is in a way that you are able to debug uh uh your application. And uh then you load the wire mock with the dependent data in behavior. And then you are going to start to create the end -to-end test against the problematic and the point of flow. Sometimes it's not just one request that fails, it's a sequence of requests. And uh you set

Speaker 2: the the the breakpoints at the in general application, and then you start to have fun debugging while you write the test that confirms the bug. You iterate over until you are able to reproduce the the bug. And um finally you fix the bug. You have right the test that confirms the bug. That means that the test proves that there is a bug in your system. You're gonna fix the bug and now your test should break because have fixed the bug. And then you fix the bug, you then you fix the test. And at the end what you have is uh a setup a suite of tests that proves that you have fixed the that bug and i any or new change is not gonna uh introduce that bug again Or at least it's gonna you are gonna be aware that oh maybe look

Speaker 2: you you are gonna break this flow. Yeah That's what I would like to talk about today.

Speaker 1: I heard that this was your first talk in public.

Speaker 2: No. Kind of in English, yes. It was super after five years more and the uh I'm back to the stage.

Speaker 1: Really well. Um yeah, are there any questions from the audience? Yeah.

Speaker 3: I'm I'm worried about test problems. Test pollution between end to end tests.

Speaker 2: Yep.

Speaker 3: How do you handle that?

Speaker 1: How do you handle test pollution with the interest in wiring?

Speaker 2: Wire mock provides an uh an uh endpoint that you can reset all the the environment You just call that at any point and everything is going to be reset. It's with one call. It's going to be like at the beginning of the tests.

Speaker 3: So you have to that at tail down. No not tel on, but

Speaker 2: maybe at Tow of uh after the the you run the test, the the individual one. Yeah. Or maybe you can randomize the data and you know yeah. That

Speaker 1: spawned another question.

Speaker 3: You had uh you wrote that you could have the the mappings as files.

Speaker 2: Yes.

Speaker 3: Does that mean that like for uh for game you can have like this mapping loaded up in the chest.

Speaker 2: Yes. Yes. Well uh Wiremark provides you a folder a custom a folder where you can load your JSON files And so you don't need to programmatically write the the democracy. So you can uh for example I like to do this to test a very big setup, uh a very big payload. Uh yeah

Speaker 1: Yes.

Speaker 3: Can you test uh stuff like latency?

Speaker 2: Yes.

Speaker 1: Can you test latency?

Speaker 2: Yeah, sorry. Yes, you you can simulate latency. You can simulate latency, you can simulate uh uh You can you can for example simulate you send uh uh uh 50% of your your your payload, then you have uh delay, you know then you send the the the left the left part. You can you can simulate There are very uh advanced techniques that that you can simulate to to file for simulate files.

Speaker 1: I have a question from myself. Um You showed that you can run it in a Docker container and also as a standalone uh jar.

Speaker 2: Yes.

Speaker 1: Is there a simple recipe for getting this up and running in a CI like uh Uh GitHub Actions, Travis, Circle CI, all that?

Speaker 2: Like this, I I I'm not aware of it. I I don't I don't know. But um yeah I I have this way That is like a bonus. Is a test container. This library, this library is pretty nice. You don't only have uh a possibility to spin a Docker container from your Python code, and uh but also you can spin Postgres uh you can spin the local stack if you need, for example, to to test uh AWS. Local stack is great because you can retrieve credentials like like you are using botol and you can retrieve the the credential data this library test containers is great to to to to simplify this process to spin up and and uh tear down the the the the the the Docker. Yes. I really like this. But of course

Speaker 2: uh that is the payment of the the Docker uh ecosystem Yeah.

Speaker 1: Yeah, and you can would you run it as a container that you start and stop for every build?

Speaker 2: Yep.

Speaker 1: Yeah. Um and uh earlier we heard about colo. Um and And uh do you see like a connection between uh the colour app and uh why

Speaker 2: that I have uh I heard about colon and uh and um uh I I have not reflected about it, but uh Uh I think they they play into different fields, right? And uh one is to for inspection uh at the runtime, this one is more for testing.

Speaker 1: Yeah, it seemed there was some latency issues in in in colo by calling a real endpoint. So maybe colo can also discover these things that way. But yeah. Any other questions from the audience? Yes.

Speaker 4: Are you uh are you using Minecraft directly or are you using something like Squiggit or Booket?

Speaker 2: Yeah, it is for this case I'm using paper and uh yes to spin the server and uh the they provide a nice restful and depending point so you can manage the Minecraft servers.

Speaker 1: I couldn't repeat the question because I I am not from the Minecraft universe.

Speaker 2: So if you'll customize one for the community. I guess that's what question, right?

Speaker 1: Yeah. Yeah. Yes. So our next talk will begin in nine minutes, ten minutes. It means that we can have a short break and um perhaps some of those drinks that We do have in the fridge can be made available. Thank you so so much for the talk, Ramalu.