Hello and welcome everyone. My name is Barkatul Mujauddin and I'm excited to be here today to talk about API testing made easy. I hope you are all having a great day so far and are looking forward to learning something new. Thank you for taking the time me to join me today. So here's a quick introduction. About me I am a developer relation intern at Keploy. I am a GSOC 2023 mentor this year only and I am also the founder of a community called Hack for Code. I am also a kubesimplifier ambassador which I'm really proud of. I believe that there are many problems in developers job and the root of maximum problems are strict timelines. Let me tell you how with an example. Yes, you guessed it right, the example is related to API testing. So here's a situation. Due to a strict timeline, we may have limited time to perform testing which can lead to regressions. Right? Again, this is a problem. So as we all know, for every problem there is a solution. All we need to reduce the bugs are just three things. Number one, we need to do the functional testing. We need a tool that could create the test cases and update the test cases easily for us so that we don't have to really write the test cases and spend time on it. We need something that could automatically orchestrate the testing infrastructure. So that's all we need. Now let's look at what if we can record the traffic from production and we can replay it in a non production environment. I know this is kind of something overwhelming and out of context, so let me explain it to you. So here's the thing. Think it in this way. This is an application serving the user traffic. Let's say application v one. And first we captured the user traffic from production. Then we replayed it after setting up the shadow database of the snapshot database. And then we need to write to compare the responses. Obviously this requires a huge operational effort because we first write to record, then we need to set up those snapshot database which are expensive, and then we need to update these snapshots timely. And then we need to write to compare the responses as well. So it is a pretty wise strategy, but it's expensive and it's included a lot of effort so far in this approach. The record and replay approach. Let's discuss some of the pros and cons we are discussing about the pros. The first one is it is a low code approach and you don't really have to write the test cases. It is easy to achieve high coverage because you are capturing the user traffic, so there are multiple flows that you are capturing and will be able to replay, which increases the coverage of the code base that your application or your API test are going through. The third one is sometimes there are unexpected user flows that you discover just via the real user traffic that the developer never did code for, but they discovered it from the real world. If we are discussing about the cons, then the first cons are the dependency states are hard to manage. This approach is good for load testing or stress testing, but not suitable for functional testing because if some of the APIs fail, there are multiple user traffic calls that fail and you have to go to each of the call and debug it. So that takes a lot of effort and a lot of time to debug and it causes a lot of frustration as well. The third cons are handling writes is always tricky in this approach. So let's come back. We were doing a record keploy via snapshot database from a production environment to a non production environment. So let's think it in this way. If you are capturing and replaying the API request and response, how about we also do the same for the database queries? So what if we create a virtual database which is just the database query request and response and not a complete database? I'll show you a deep dive with an example later in this talk. But in this approach also, there are some downsides. Like you have to add support for each of the dependencies, right, that your application is talking to. For example, if your application is talking to MongoDB, then you need to add support mocks the MongoDB queries or to capture and replay that. This becomes brittle in case your API schema completely changes and you have to rerecord the user traffic and replay it. So these are the downsides. But the upsides are the complete database did not need to be replicated to some other environment, or neither. It is expensive because we were storing just the query data. So what we just discussed, we are going to basically virtualize that. So to give an example, let's say in an application, if we request an API with a particular user, it returns what sports that particular user plays. So the user has Thompson and we got the response as cricket, volleyball, karam and boxing. So in this case we have the application talking to MongoDB, which has all of the relevant data. Typically if I am going to record replay into a different environment, I would capture the request, run it again in my test environment, and this time maybe user Thompson isn't there. What I mean to say is it's not the same state. So the problem is how do we ensure that the exact state is consistent with the test case that we captured. Now in the same example, if once we do dependency mocking, we can instead of maintaining the test database, we instead kind of maintain a mock. So when we capture the Getgame request, we capture the queries and the response that we got from MongoDB and just package it along the test case. So now when the same thing happens while we are testing, we can just return the same response that we got for the particular request. So it's basically mocking, but actually kind of replaying that exact database response that we captured and then of course things will be consistent. So as of now, we have discussed the problems we were facing right now as a developer and how record, replay and dependency approach can solve these problems. So what basically Kipployoy does is keploy converts your API cases to test cases automatically. All you just need to integrate keploy in your application and it automatically mocks external dependencies for you. It also detects the noise and accurately reduce it automatically. All of these three can be done by keploy easily. How? Let me show you a demo. Let me show you a demo of how keploy can generate test cases as well as data mocks for your backend application. So in the demo I will take a Javasample application which is an employee management application and it does a crude operation on employee. So this is the main repository of keploy where the server lies. You can just simply install it. Now I'm going to follow the samples Java repository. So I have already installed keploy server and I'm going to start it. And I have also cloned the sample Java application here. Now to integrate the Keploy Java SDK with my application I need to follow certain steps. First I need to add the keploy dependency. So I have added it here. Then I need to also import the keploy middleware with my main class. I have done that here and I also need to have the agent jar. So how you can go to it is to going to maven central download the latest version of this agent jar and put it in the main directory of your application. Now the last thing I need to do is to set up this agent. I have just added the vm options as Java agent and then gave the absolute path to this agent jar. And I have now added the environment variable which is keploy mode record because I'm going to make API cases and record the test cases. And denoise is true, it just means that it is going to ignore all the random fields like timestamps or random numbers which are going to change in every API call. Now let's go ahead and run our postcase instance first. So I'm just going to run the postgres instance. It is running now and I'm going to start the sample application. Now let's just go ahead and make an API call. So I have this post API call which adds an employee record. Now here are the test cases and mocks generated. Yeah, so in the test case I have the request and response header and also I have the mocks for the Postgres instance. Now let's make another API call to get the user that we put on employee id one and there was another test case generated. The interesting part is that since Postgres is a SQL based database, it captured this whole query and you can generate the test cases and mock file mock like that. Now let's go ahead and simply run the test cases that we captured. So first we need to set the environment variable of keploy mode to test. Yeah, now let's run the sample Java application. Yeah, you can see on the keploy server that both the test case is run and passed. Yeah. Now let's introduce an error. Let's say we have a field named changed which is being queried. So instead of first name it will query name from the postgres instance. Now let's stop the postgres instance. Even without the postgres it is going to run because we already have the mocks. So we didn't need postgres. So yeah, it has run and one test case is passed and one failed. Let's go into detail. So it is why? Because the first name is now different. It was not able to query the name parameter that we changed and thus the first name was null. So this is how you can capture the test cases quickly, run those and achieve good line coverage with keploy. I hope you have understood how keploy works. So I hope I made it clear how you can integrate keploy in your application and how it works, how it can generate test cases and data mocks for you automatically. So thank you and that's basically about it. And you can also find us on GitHub and if you want you can star us. Also, we don't mind and feel free to join our slack channel. We would love to have all of you in our community. And thanks again and thanks for joining today. And feel free to reach to me if you have any questions. Till then,