 Hi everyone. Good evening. I am Anisha Narang and I work as a senior quality engineer with Red Hat. I've been with Red Hat for over six years now. I work with different test automation tools including Selenium Python, Pro Tractor, Water Ruby. I've spoken at different tech conferences on topics related to quality engineering and this is one of them. I'm really happy to share with you all that this is going to be my tenth talk. Other than work, recently I've started with travel blogging and self-guided yoga. Before I get started, I want to know how many of you are QE's in the room? Perfect. Which type of testing do you like more? Do you like UI testing more or API testing? Which is your favorite? APIs? Okay. Hands for UI? Alrighty. We have candidates for both. Perfect. Thank you so much for coming to my talk. So the agenda of the talk is I'm going to quickly run you through an overview of REST API. Introduction to API testing. We're going to see what are the different API testing frameworks available for us. Quick introduction to lemon cheesecake framework. Understanding what lemon cheesecake has to offer, all the matches and the assertions available with us. And we're going to generate some really, really awesome reports and a quick demo at the end. What is REST API? API stands for Application Programming Interface. API enables communication and data exchange between two separate software systems. Now you all must be aware, familiar with the process of booking airline tickets, right? Now let's say you're not using the airline's website, but you're using an online service portal which aggregates information from different airlines. So that is when the online travel portal such as Kayak or Expedia is interacting with the different airline's APIs to get you all the information at one place. What is REST? REST is nothing but an architectural style or a design pattern for APIs. REST stands for Representational State Transfer. It means that when a REST API is called, the server will transfer to the client a representation of the state of the requested resource. Now the representation of the state can be in adjacent or in XML format. Now there are two points to it. One is the API endpoint which and the second is HTTP method. API endpoint is nothing but an identifier for the resource that you're interested in. It's the URL of the resource also known as the endpoint. HTTP method. It's the operation that you want to perform on that resource in the form of an HTTP method. The different HTTP methods available to you are get, post, put and delete. We're going to talk a little bit more about these HTTP methods in the next slides as well. What is API testing? API testing is a type of software testing that validates the API, that validates the application programming interface of any application. In short, you send calls to the API and verify the response. You need two things for this. You need a tool to drive the API and you need to write your test code to test the API. Now the HTTP methods. The get method is used to retrieve information from a given server using a given URI. It provides only the read access. The get method corresponds to the read operation. All the four methods they correspond to the CRUD operations we have. Get corresponds to the read. Post method corresponds to the create operation. It's used to submit an HTTP to a specified resource and it makes a change in the state. So let's say you are filling up a form. That's when you're making a post request. Put is for updating. It updates the targeted resource with the content that you sent. So let's say whenever you edit a form, you edit some entries. That's when a put request happens. A delete request is pretty self-explanatory and the delete method, it deletes the specified resource. Now different types of API testing frameworks that we have. Now the best thing about API testing is that you can do it with any programming language. Curl provides a generic and a language agnostic way to demonstrate the HTTP requests and responses. Postman is a Google Chrome app. Postman is something that you all must have heard of or used at some point in time. It's a Google Chrome app for interacting with the HTTP APIs. It gives you a very friendly UI for constructing the request and reading responses. Jmeter is a very widely used open source tool for API testing. Though originally it was created for load testing but it's very widely used for API testing. Karate is a framework that works out of the box and you don't need to have any prior programming knowledge in order to write your API tests. PyTest is a testing framework which allows you to write test codes using Python It's one of the very popular testing frameworks in the Python world. But there is more with Python. Now it's time to try out some lemon cheesecake. Try cheesecake in the room. Anyone who doesn't like cheesecake? Yes? Okay. So everyone loves cheesecake. So you're definitely going to love this framework as well. Okay. So lemon cheesecake is a functional test framework for Python. It makes reporting a first-class certificate and it also provides you with all the modern test features such as fixtures and matchers. It allows you to filter your tests using tags, add metadata to your tests, generate reports in different forms, have nested suits as well. So these are a couple of features that lemon cheesecake provides. Now we're going to do a little bit of deep dive into the framework and see how we can write our tests. So to get started, it's pretty easy to get installed. You just have to say pip install lemon cheesecake and you can get started. Writing your test suit, the command says LCC Bootstrap. You are the name of your test project. So it creates a new project directly called TestProject containing one file which is project.py. It contains all the configurations of your project. And it also initializes empty directory suits and fixtures to add your test suits and fixtures. So you see here, this is how the project looks like. This is what a suit looks like. So first you do all the imports, all the necessary imports. We're using the request library to make calls to our API endpoints. Now a suit can be defined in two ways in lemon cheesecake, either as a class or as a module. If it is defined as a module, you need to have a suit variable with the description key. So here's the description key. So whatever you write as a description of the suit will be displayed or will add to your test report. That is what we are always looking for to have more and more information in our test reports. Now each test needs to be decorated with LCC dot test. And you can specify in one line what your test is about. Let's say here for this test we are saying verify that the get request for my endpoint gives a 200 and okay. And I'm performing my test here. I'm adding a set step here. So this is another good feature that lemon cheesecake offers you that you can have this in your test report as a step that's added. Now you make your request and you do check that. Here you see there are three different type of matching operations that have been performed. Take that, require that and assert that. Now you might be wondering why I use these three and there is a difference between these three which I'm going to cover in the next slide. So this is what an overall suit looks like. Running the test suit is pretty easy. You only need to do LCC run and it will run your test suit. You can also see your reports on the console and this is what the report looks like on the console. It also tells you what all values did it get at a particular endpoint or whatever matches was it trying to perform. So even if the test fails, you see what was not a match here, right? Okay. So these are a couple of matchers that we have here. The list of matches is pretty self-explanatory equal to not equal to true, false. Some of the interesting thing is that it offers you is dictionary is list. So let's say and has item, let's say you want to verify that if a particular response has a particular entry or not, you can always use is a list and you can use that particular list has an item as expected. You can match the actuals versus expected. Now we come down to the most interesting part, which is the matching operations, right? The first is the check that. So what it does is it runs the matcher, it will log the result and it will return the matching result as a Boolean, right? So we always want to have more than one checks in a particular test. Let's say we want to have five checks in one test and if the test fails, the third check fails, then we do not get to know what happened with the fourth and the fifth check, right? So that's where this check that matching operation comes handy. It will not abort the test, but it will just tell you that if the test failed, require that, it will run the matcher, it will log the result and it will raise an abort test exception in case of a match failure. Assert works the similar way as the assertion logic works. It runs the match and it will only log the result in case of a match failure and it will raise an abort test exception, right? Okay, so now let's consider this as a sample JSON output, right? So we have a few key value pairs here, ID, name, username, email, address. Address is again a dictionary here, phone and the website, right? These are a few key value pairs that we have. Now let's use those matches that we studied and write some tests based on the JSON response that we have as a sample JSON response. Okay, so the first test that I'm trying to do here is, verify that the get request for users one contains the required parameters. I create my get request using the request library and I hold the JSON response in a result object. Now all I need to verify is that it has an entry name, right? Now the second test that I'm trying to make is that the email is a valid email address or not. That's all I'm bothered about. So I say if has an entry email, if the dictionary has an entry email, add it contains this string, add the rate. A few equal tos is a dictionary and now let's say I want to make sure that the address has an entry city which is equal to this particular name, which is what we are expecting, right? So that's where the check goes in. We're also trying to do a post request, right? Now I'm trying to send the data to a particular endpoint. So that's how we frame a post request and so this is the body that I want to send. The response, it's the request.post. I create my post request and then all I'm trying to make sure is that if it was created successfully by checking for the response code, right? So I want it should be HTTP to a one created. That's what the HTTP response that we are verifying. Now we want to just log what was the response of the request that we made. So I'm just adding a log info here and this will be logged in my reports. I'm again going to check that here. Okay. So let my cheesecake provides logging functions that give the user ability to log information beyond the checks. These are the four different types of logging operations that you have. It's pretty self-explanatory. It comes in handy when you're trying to run a test with some random data and you want that random data to be showed up in the report as and when the tests are running. So this comes in very handy then. Now generating some really awesome reports, right? So what's so awesome about the reports is here that it tells you how many tests were run, how many were successful, percentage of tests, time taken by the test, and that it lists everything, right? So the suit description that we gave at the start, it is here in our reports, right? It will keep on adding as more and more tests are run. So here for this test, I have like four tests. So even in this test, which says contains the required patterns, it had five, it had four different checks and we have the output for all the four different checks that you were trying to perform, right? Okay. So we're pretty much well in time and it's time for some demo. Okay. So like we discussed, this is how the test suit looks like. It's just a very basic test suit, something that we already discussed, but this is the test that we are going to run. You can see the imports at the top, the suit description, and the four tests that we have. We have get request, post request, and we also have the delete request here, right? So now any of you remembers how do we run the test? All right. Everyone was listening. Perfect. So we simply do LCC run and we see that all the four tests that we were trying to perform run successfully. And this is usually the output that we see when we have the test suit and the file names appended and we need to figure out what the test was, right? So this is, but we can also see the report on the console, right? Now, if we do LCC report, we see the report here. We see which were the test pass, what were the output responses, what happened during the test. We even have an info here, right? So now making sure that the delete request was successful. I don't get anything in the JSON response because the delete request that I made was a success. I'm trying to add an info here. Okay. Now going back to, so we did, I did mention something about check that, require that and assert that, right? So now we're going to see how the test is failing and how does it impact the logging here? Okay. So let's do it for this test. We see four checks here, right? So there are four different checks here. And now if we go back here, we have one, two, three, five, right? We have five, five checks being added here. So now do you notice that the one with the assert that is not logged? Because like I mentioned, it will log the result and abort the test only when it fails. So now let's say if I, if I change what is expected and I again run my tests. So my second test failed. And if I look at the report, you see only two checks here. And my third check failed, which says, expect the response to have entry user name that is equal to Brit. But what did the response get? It got bread, but we were trying to, the unexpected output was Brit, right? And it says error. The test has been aborted, right? But now if we try to do it, let's say this one is a pass. And let's say, okay. Let's say we do this, okay? We tried, we are trying to make the second test fail. So we expect that it will log the result and abort the test. Okay, so now if you see only the first test was logged, the second it was logged, we did get to know what was expected and what was not, what we got. And the error has not been, and the test has been aborted. We miss out on the other five checks that we got, right? But if we, so, okay, so even if we make this to check that, all the five checks will be logged and all our tests pass now, right? So if you see here from four, the number of checks being added changed to five. And all it is trying to verify that if it's a dictionary, if it's a collection or not. And you also see what the response was for that particular key, okay? So this is pretty much it. And you can also see the HTML reports here. So this is what the report looks like. And when you open any of the reports, you can see what, so you remember we added a set step here, this gets logged, and it also tells you what response. So you also see, right, one of the things that you might have missed is, we only mentioned the response, right? And the entire statement is formed by lemon cheesecake. It tells us what it is trying to verify here. So here we have all the checks mentioned, right? So this is what the report looks like. All right, so this was the demo pretty much. This is just a quick recording of what I've already showed you. And thank you. Any questions, feedback, comments? Can we add something to the header as well? Yes, absolutely. Because that's the request library. So you can use the request library as you want. So lemon cheesecake is just the framework that is used to run the test and give you better reporting. So now to add the header or to do anything with the request, you always have the request library and you can use it as you want. So is this something you wrote? No, it's all to be written by somebody else. Just that the framework is not very popular in this pie test. I was just wondering if there was something like pie test. Is it mainly the reporting or is it what would be the issues with the information? I think reporting is one of the... All right, thank you so much for coming to my talk.