What is JSON Schema | Bondar Academy
Course: Playwright API Testing with TypeScript
Module: Schema Validation
Instructor: Artem Bondar
Lesson Summary
In this module, we explore JSON Schema and JSON Schema Validation . JSON Schema is a JSON object that describes the structure of another JSON object, defining the required properties, their types, and the overall structure. Importance of JSON Schema JSON Schema is crucial for preventing integration issues that arise when API responses change unexpectedly. For instance, if an API removes a property like age from its response, clients may encounter errors such as your age is undefined . With JSON Schema validation, we can ensure that the expected properties are present, thus avoiding such issues. Creating JSON Schema To create a JSON Schema, developers can use online tools such as a JSON to JSON Schema converter . This tool can automatically generate a schema based on a given JSON object. Example of JSON Schema Generation When a response contains a property text of type array , the schema specifies that each item in the array must be a string . If the response structure changes, such as returning a number instead of a string, the validation will fail. Handling Complex Objects For larger JSON objects, like a list of articles, JSON Schema can significantly reduce complexity. Instead of creating assertions for hundreds of properties, the schema can succinctly define the structure, making validation easier and more efficient. Contract Testing JSON Schema validation is a form of contract testing , specifically provider-driven contract testing . This ensures that the API responses conform to the expected schema, helping to catch integration issues early. In the next lesson, we will demonstrate how to validate JSON schemas using Playwright and automate schema generation.
Video Transcript
Hey guys, in this module, we're going to talk about JSON Schema and JSON Schema Validation. So first of all, what is JSON Schema? JSON Schema is the JSON object that describes the structure of another JSON object. So it's a contract that defines what properties should be in the response, what types of those properties and overall structure of the entire object. Let me show you why this can be super useful. Remember previously in our lesson, I was showing you this simple example of client-server application. When clients send the request with username, password, server provide the response with first name, last name, and age, and then client displays this information, John Smith, your age is 35. But imagine other situation when developers of the API suddenly made some changes and removed the age property from the response. So when the client request username and password, response coming back just with John Smith, but without the age, what's going to happen? Then in the application, you may see something like this, your age is undefined. This create integration issue and actually a breaking change. But if we would have a JSON Schema that would validate that we expect to have age property, then we would not have this issue. You may ask a reasonable question, but I can just create an assertion for each of the property in JSON object and validate that way. If the property is not there, then the test should fail. Well, this is a very simple object with just three properties, but real JSON objects in real APIs may have a hundreds of properties and it will be just a nightmare trying to validate all of them. Also, it's not needed and we talk about it a little bit later. So now, how would you create a JSON Schema and how does it look like? So you can Google different online tools like JSON to JSON Schema converter, and this is one of them on transform tools, JSON to JSON Schema. This tool can take the JSON object and convert it to a JSON Schema. So let's convert some of our objects real quick. So going to the Postman, this is a text endpoint, I send the request and that's the response that is coming back. So let's transform this response into the JSON Schema. I'm copying this response, pasting right here and pasting right here. On the right, you can see the schema is generated. So let's review it one by one. What do we have? So schema and title, we can skip that. Then, the type of the response is the object. You see it's a JSON object and schema defines. Okay, the object should be in the response. Then, what properties this object has? This object has just a single property, which is a text. Text should be type of the array. You can see the text represent the array over here, and the items of this array should be a string. Also, this text property is a required property in this response. So what all that means? It means that, for example, if our response would suddenly return numbers instead of the strings, the assertion would fail because schema requires the items to be a string. Or if tags, for example, would return an object instead of the array, the schema validation would fail as well because the schema explicitly say that response type have to be an array. Also, this property is required. If this property, for example, is optional, you can remove this property completely from the schema. Then, if property does not return, the schema validation will not fail. But if the property name will be changed, for example, from tags to just tag, then assertion will fail because the property name is different. This is how the schema works. Let me show you a second example, for example, with the articles. This is list of the articles. Looks at this giant object with 200 lines of code. Imagine creating the assertions for 200 lines of code. It would be just a madness. I'm Control A, Control C, and going back over here and pasting it over here. New schema is created. Look, this schema is smaller than our actual object. This object has 211 lines, but the schema is just 85. Why is that? Because our object has a repetitive information. It's object with articles, and each object has absolutely the same structure. This is object number 1, number 2, and so on. Every single object in the response has slug, title, description, body, and so on. Then again, slug, title, description, body, and so on. Schema knows about it. Schema knows that we have a repetitive type of response. It's over here. It's articles. The type is array, and the items in this array have to be an objects, and those objects should be this type, slug, title, description, body, tag list, and so on. Also the types, the slug have to be a string, title have to be a string, and so on. For example, favorite have to be a Boolean, favorites count have to be a number, and so on and so forth. Then if something goes wrong, if any of the property will be missing or the type of the value will be missing and we will validate against the schema, we will not miss that something is wrong with our object. We will not miss the mistake because you see the object sometimes can be pretty overwhelming. But if you just compare object to a schema, if just a single item or a single property went off, you immediately will know about it. You also might heard about the concept called contract testing. There are two types of contract testing, is a consumer-driven contracts and provider-driven contracts. When we do validation against the response of the API, we essentially are doing a provider-driven contract testing. Because API is our provider and schema is our contract of expected response from the API. By doing this validation, we are doing technically contract testing, provider-driven contract testing, which is very powerful to catch the integration issues. In this module, I will show you how to make a validation of the JSON schemas using the playwright, how to generate the schemas automatically and maintain them pretty easily. See you in the next lesson.