 Welcome to the talk from Atmaram Naik. He's with us today to talk about automation beyond test, test data as code. Over to Atmaram. Hello everyone. So whenever we talk about testing, testing is about validating the result of action performed under free condition. Like whenever we test, there is some given pre-condition. Under that pre-condition, we do certain action and we validate the result of that action. And hence, to test, what we need to do is we need to bring system in certain state as per pre-condition. So that's what we are always doing while testing. Yet, we spend significant time on test data creation to bring system in the class state. That's the harsh reality of testing. I mean, performing testing is easy when the data is present and pre-condition is present. And that's what my talk is going to be about automation beyond test or how you can automate data creation and use test data as a code. So before jumping into the talk, I'm going to talk about myself. My name is Atmaram Naik. I'm working at Code of Technologies. I'm maintaining an open source tool called as a part. I am passionate about writing good code. Here are my Twitter handle, LinkedIn handle and Twitter writers. Do tweet about, do share on social media about this talk if you like it. So before jumping into the actual talk details, I always like to demonstrate the concept with sample application. Hence, we have created a sample application called as a to-do app. Is any app to do to do app that we generally create for testing or development purpose and learning development or something like that. But specialty of this to-do app is like you can tag to do with certain tags. For example, here, help you make on contribution of open sources tagged with open source and other right. So let's see how the application looks like. So we are going into the to-do app. Here are the tags, personal, office, community, family. And I can create a to-do, prepare presentation. This is for community. And I have added a to-do. Similarly, I can delete this to-do, I can archive this to-do. That's the simplest app we have. And there are lots of possibilities about these apps to test. And let's talk about those possibilities. So there could be situations in while testing these apps. Like we need to create n random number of tags. So there we saw only four tags. We want to create multiple tags in the app. We want to create one single to-do. We want to create n random to-dos. Or we want to clear all to-dos to bring the system into the clear state. So situations could be endless, but let's talk about all these four situations right now. And to bring the system under that particular state, we need to create this kind of data. So what we are going to do is we are going to use Postman to do this thing. So what I'm going to do is I have created a Postman workspace for doing all of these things. So this to-do app is backed by a backend. And that backend is having API called as a tag. And once I send to that API a get request, I get a list of tags. Postman has this ability of writing scripts. So you can write post processor scripts, which will do certain things. Here in this script, what we are doing is we are setting an environment variable called as a tags with whatever data we have got. We'll see why we need to do this, but we are just gathering all tags and we are saving it somewhere. Now, when we want to create one random tag, what we just need to do is we need to give it a random data. So Postman has this ability of different random variables. So I have used a random variable called as a random city. So we'll create tags by city name. So once I send this, it has created North Ramona as a tag. So let's see whether that tag appears on the screen or not. So once I refresh this tag, North Ramona is created over here. Now, if I want to create n random number of tags, what I can do, I can run this collection n number of times. So Postman has this ability of running the same collection n number of times. So let's say I run this for six times and it has created six more tags. You can see it has created six more tags. Similarly, when I want to create a random to do, the to do API is slightly different. The body for to do API is name of the to do and the tags as well because these to do that tag with tags, right? So I will need tag IDs passed for the to do API. And that's why we have pre request script, which will generate this tag IDs. And that's that's why we case this tag response. So he from here, we'll be getting a random tag IDs using the script that I have created. Once I send, it has created to do added from postman and it has added tag with ID tree. Let's see. So to do added from postman and it has added community tag. Similarly, if I want to create 10 random tools as just done and entire data is available. So that's the power of scripting. That's the power of writing code. You can write a code to create a data. And that's what I'm demonstrating. Now I want to clean all these tools. What I need to do is get all the tools. So we have get all to do get the IDs of the to do and say save it somewhere. So that's that's what the scripts are doing. These are saving IDs in tag IDs and delete each to do one by one. So once I run this collection, you can see it in console log. It has deleted each to do by ID. And let's see what has happened to our application. Yeah, it has deleted all the tools. So that's the power of postman as well. You can use postman as a tool for doing so. But postman we generally use only with static data. Here we have used the ability of scripting of the postman. There is one more tool. This is tool used for test data as code only. This has a specific ability for writing test data as code that is called as a core. And we are going to talk about that tool as well. So what I'm going to do is I'm going to go to IntelliJ idea. This tool has a plugin with IntelliJ idea as well. It has its own programming language. I'm going to do same thing. I'm going to add one tag. This tool is programmable. Now it has added a tag with name from core claiming. If you see it has added a tag from core claiming. Similarly, if I want to add n random number of tags. It is asking me tag length. How many tags I want to add. So if I say I want to add seven tags. And if I refresh the data. It has created seven more tags from core from core. All these appearing from core are created from the school. We won't go into the details of the script. It will be a lot of time just to utilize the time. We will just see how the scripts are working. If I want to add to do similarly we have a script add to do. It is asking me to do name. So I will say created by core. Now it is asking me number of random tags to add. How many tags I want to add. So I will say I want to add four tags. And it's done. So you can see this tag is created. This to do is created with four random tags. Isn't it so simple like you can run the script multiple times. You can run the script for creating one more to do. Just give it some name. How many tags you want. And it will add a to do. And where will you use it for testing whether if I add some to do with 10 tags. Let's see our application is breaking on UI when I add 10 tags. And you can test this possibility of testing with different data is possible just because you did test data as a core. You programmed how to create a test data. Similarly, I can add random number of to do to do is to add how many to do is let's say I want to add 30 to do is minimum number of tags. I want to let's say two minimum number of tags. Maximum number of tags. Let's say six. And it has added all tools. So it has created. You can see there are so many bugs on this application because I made it in one day. And we can realize those bugs because we have that kind of data. And similarly, when we want to clean up to do is we can just run cleanup script. It is doing same thing which postman script was doing. It was getting all tools and it was it is deleting to do one by one. So that's that's the possibility. I wanted to talk about of writing this data as a code. The scripts are simple to write. You can see there. These are more like one or two line of scripts. So that's about demo of car. The golden rule that car uses is it will correlate to whatever it can rest. It will ask to user. So it was asking me certain values asking me certain values because those values were not specific. So it will ask those values to the user. So that's the golden rule that car uses. And while testing. What if I tell you like this application which is displaying these tags. These tags are coming from another service. This is tag services, totally different service. Let's say it is a third party service. And in such situation when you have third party dependencies, we are one services dependent on third party service or another service. There could be multiple situation situations like this tax service refreshes data tax services down. And there could be that you want to inject fault into tax service and you want to test. So that is that is where the service virtualization helps. So I'm going to demonstrate a service virtualization that is also possible with this tool. So first thing is I'm going to shut down the tax service and let's see what happens. First I'll create some first I'll create some data. So once I shut down that shut down the tax service, you will see though all those tags which we created were lost. Right. And that's that's what we saw all the tags were lost. So I will show a quick video of the service virtualization. Because we are running out of time. So I'll show a quick video from the desktop. So what I did is I shut down the service and you will see that data is unavailable for all these tags. Now, when I start the service again, we will have certain data available like community is available because the data was refreshed. Certain data is available, but certain data is not available. Data is refreshed. Now what we are doing is we are running a virtual tax server. This is a service virtualized tax server. It is running on 87204. And we are restarting our to do service with injected virtual server. So this service is starting. So to do service has been started with injected virtual server. There are four tags now, but we can do everything that we did. During the data creation. So we created 12 tags. We added 100 random to those and entire data is available. So this is kind of service virtualization that is also possible. So actual service is not running actual tax service is not running a virtual tax service is being pointed. And that's how service virtualization can work. Now I'm going to I'm going to talk about some plus points of the car. So car is programmable. You get more power by writing less code. You can do dynamic service virtualization. Most of the service virtualization tools available. They can do static virtualization, but you can do dynamic service virtualization. It is available with IntelliJ plugin. You can directly run the scripts from IntelliJ. And it is tailored for testing data and automation. And it is good for generating fake values. So we generated some fake value using car. But there is caution with this tool and that I would like to remind everybody before starting using this tool. It is early stage of experimentation. This is all my, all my, my brainchild. I'm, I'm trying to experiment this, although we are using it for production, production ready applications in our company, but this is all my brainchild. There is a learning car. It has its own programming language. So you need to learn that language. It is slightly less documented. So you won't find much help while dealing with something. It is sometimes restrictive in features. Some features you might won't find. You can create issues on the repository and I'll try to create those features. And yes, of course, it's buggy. It's, it's in early stage. So it's buggy. So with that caution, I would like to close on the notes. Don't just automate test. Okay. Automate repetitive task as well. So test data creation is repetitive task. We spend a lot of time. You can be become more productive by saving that time. You can spend that time somewhere else. Build reliable strategy for test data creation because you spend a lot of time to create test data. Use sandboxes, fake stars, mocks for things which you don't want to test like tag services, third party service. This is beyond test boundary. I don't want to test that service. So use sandboxes, fix for that and look out for ready made tools for doing so. Don't reinvent the wheel. There is a postman. There is scripting ability in postman. You can anytime go for postman. And if you feel so much sophisticated, like your application is complex, you need to do dynamic service virtualization. Want to create lots of data, tagging and all you can use car as well. So that's pretty much that I wanted to cover. Let's go to the questions sections now. Yeah, nice session. We have one question from Venkat. Nice utility. Would it be fair to assume that this only works for restful APIs? Yeah, that's that's a nice question. It is built in consideration for restful API right now. But there is version 0.2 also coming, which will help you to put data into databases as well. It will version 0.2 will be supporting PostgreSQL and MySQL initially. But there is a plan for supporting directly putting data into databases and all. I purposely kept rest as the first thing because that's the best practice for creation of test data. You shouldn't directly interact with databases. This structure do change often and your test strategy should not depend a lot of on database. Rather application programming interface, which is nothing but API. API's contract don't change that often or even if they change, you'll get notified. But if database structure changes, not developer is going to tell like, I have dropped this column or I have added this table or something like that. But APIs you will know. Thank you again, Madam. Great session. Thank you all.