With that we now at the Hello World section of this training. And so I will explain how Karate looks like. Some of the things that went into Karate design decisions, how it works for API testing. And then I would point you to the documentation. You would be able to actually use the documentation. Follow along with me as I step through getting to write a similar test from scratch. And one of the things that should strike you straight away, if you look at this example, is that, it's not any programing language that you're used to. It's not Java, it's not .Net, it's not JavaScript, or Python. And it's designed to be very simple. In fact, it reads very much like plain English. And I know some of you are familiar with Cucumber and you can straightaway see scenario given when then and the BDD flavored syntax, which is the first word in red on the left hand of what you see on the slide, it needs to be called out that Karate is not a BDD framework. It's a kind of a common misconception.

And you should think of Karate as more like a programing language that is very scriptable and gives you great power as you start getting into more advanced concepts while still keeping it simple, of course. The last thing on BDD that I do want to call out now is that given when then are purely here for cosmetic reasons, they don't really do anything or they don't drive any behavior in the backend and so on. In fact, most teams nowadays that I work with instead of given when then you can put a star or an asterisk symbol, which is good enough. You don't need to worry about whether any line should start with given when then.

Okay, so with that, let me get deep into some of the aspects that make Karate what it is. First, JSON is native to the syntax and you can see, by the way, JSON is one of my favorite things now. I find it one of the most elegant ways to express data, which is great because API is, as you know, involved a lot of JSON being sent as well as received. And one of the things I do need to call out about the way JSON looks like in Karate is that it's lenient.

For example, here I'm pointing to the name. It doesn't not require double quotes around it. In fact, single quotes are sufficient and this is exactly how JavaScript programmers work with JSON on a daily basis. So that said, you could use double quotes and stick to JSON if you want to do, which is interesting because what it means for teams is that you can cut and paste to JSON from any legitimate source. There are plenty of places where you could get JSON. If you ask your developers, for example, and you can cut and paste them straight into a Karate test and it would just work out of the box.

Okay, So next Karate is something we call a DSL or a domain specific language. And let me explain what that means and why the DSL terminology is used. If I call your attention to the first word on each line, you URL request method status, but you straightaway see that it makes sense from an HTTP or REST standpoint. This is something immediately folks, anyone who has got experience with the rest would connect with straight away. And you see how clean and less noisy a Karate test is. These key words are very carefully designed to be readable.

For example, if you look at a Karate test, you will immediately know what kind of API call is being made, whether to get or post, whether you're making the get and the post, and what are the parameters and data being passed. Matching is what I'm showing you now on the slide. The match keyword in Karate is where we do assertions. You can see on this line in a single line of code, Karate is capable of comparing to JSON payloads.

Here we have the response that came back from the API request that we made. And while we can validate all the data, for example, we are checking of the name is exactly equal to "Billie". What is happening here that I'm pointing at the #notnull. That's really interesting because in real life APIs tend to come back with a lot of unpredictable data. You have random values, in this case the UUID, a generated identifier. And the great thing about Karate is match or assertions capability is that you can validate all the data elements that came back from a JSON payload or a response, yet at the same time you could ignore or you could work around those troublesome values, which you cannot predict. 

So that's something people really like about Karate. And keep in mind that in real life, even though this is a hello world example, you can have a really complicated JSON come back and we will see one example in a moment as we walk through the first example that you can try out. The last point I want to cover on the slide is that Karate is great at chaining together APIs. When you're really doing a functional test of APIs you would be calling multiple APIs in sequence and using what came back from one response into the next request. And you see that happen here on the third last line where we say from the previous response, take the ID value and use it as a path parameter and good Karate test can involve five six sequences of API calls and when you look at the report, you will actually see a very nice story in terms of what APIs were called and what business functionality were these APIs in working.

Comments are closed.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}