Test Authoring With Katalon: Data-Driven Testing

Hi, welcome back! In the last chapter, you've learned to run data-driven tests with internal data in Katalon Studio. However, in many cases, you'll need to use different data files from other teams to run your tests, such as developers, clients, marketing, sales teams, and so on. So, having the option to import and use external data sources would be convenient and save up lots of time for data setup. In this video, I will show you exactly how to do so - using external data files to run data-driven tests with Katalon Studio.

The steps are quite the same as in the previous lesson. First, create a new test suite - ''DDT with MS Excel Files''. Then, add a test case. I will use the same one which has already used variables. Next, we need to prepare our test data. Open your Excel file on your computer. Fill in the data, just like when we were creating the internal data in Katalon Studio. You should give the data columns the same names as the variables in your test cases so that you can map them easily. Alright, let me fill in the data real quick... First, ''Atlanta''... Second, ''New York''... And lastly, ''Tokyo''... Save this file.

Then, go back to Katalon Studio, create data in the Data Files folder. Give it a name. Here I name mine ''excelfile_100cities''. A tip here: you should get a consistent format for naming your data files to find and manage them more easily. Alright, keep the type as Excel because that's what we want. Click OK. Continue to click Browse and select the Excel file . You can also choose the sheet you want to use. Save it and move on to data binding.

Select the test case. Click Add in the Test Data section and choose our Excel data file. Then, click Map all. The two variables have been bound to the two data columns that have the same names. Save it and run this test suite. It's going to run the tests according to the test data order in the Excel file. First, it searches for Atlanta... Now, it goes for New York... And lastly, Tokyo. All of our tests passed. Easy, right?

The good thing about Data-Driven Testing is you can add more test data without changing anything in the test case or test script since it is stored separately. Let's say, I want to test with another city. All I need to go to the Excel data file and add it in. For example, here I type in ''Miami'' for the city input and ''Stays in Miami'' for verification. Save this file. In case you run your test cases with CI tools and store your automation projects in a version control system like Gitlab, you will need to commit the data file change you made. Otherwise, it will use the old file to run the tests.

Let's run the test suite again to see whether it will automatically update the new test data. What we're expecting is after running the tests with Atlanta, New York, and Tokyo cities, it will continue with Miami, which we've just added. Let's wait for a bit... Ah, here it is. It runs for the 4th time and searches for Miami. All done. The report shows there are 4 ''test cases'' which are actually 4 iterations. The same goes for the Log Viewer below: Atlanta, New York, Tokyo, And Miami. That's how you apply Data-Driven Testing with Katalon Studio using an Excel file.

Another type of file you'll likely encounter for storing and retrieving data is CSV. It is a simple text file containing records separated by a delimiter, often a comma. Due to the simplicity and widespread use across different platforms and systems, CSV files are a preferred format for data-driven testing.

With Katalon Studio, the steps are similar to how we use an Excel file. First, create or get a CSV file. Then, create a data file in Katalon Studio and import it in. Remember to choose the CSV type and select the separator the same as the file. Next, bind variables to the test data. Finally, run the suite. That's how you apply Data-Driven Testing with an Excel or CSV file. In the next lesson, we're going to show you how to run data-driven tests with an external database and how to bind variables to different data sources. See you.

Hi! In this lesson, I'll show you how to configure and run data-driven tests with an external database. Currently, for Data-Driven Testing, Katalon Studio supports many databases which use Java Database Connectivity (JDBC for short). If you want to use any other one, just need a JDBC driver. You can check the latest updates in Katalon Docs to get the compatible database management systems and Katalon Studio versions.

For this demo, I will use Postgres, also known as PostgreSQL. It is a free and open-source relational database management system that emphasizes extensibility and SQL compliance. To set it up, you can go to postgresapp.com, follow the instructions and learn how to install a Postgre DBMS from there. You can also download and install pgAmin from pgadmin.org/download to manage your database more easily. You should skip this precondition step if you already have it.

Here, I've already installed and set up my local Postgres and pgAdmin to manage it. Now, I'm going to prepare the data table. Go to Schema > Choose your schema, mine is Public > Select Table. Give it a name. Then, click on Column > Add row. I'll fill in some names here. Click Save. Next, I'll add values to these columns. Right-click on the table > View/Edit Data > All row. Double click on the blanks and fill in the values. Like the previous examples, I will add 3 cities here... Atlanta... Miami... and New York. Then, click Save on the toolbar.

To check, I'll write a query to get the data from this database. In the Query Editor, I type in the statement ''Select city, expected from db_ddt'' then hit the Run button. Here it is, our data table. Everything seems good. Let's head back to Katalon Studio.

Go to the Data Files folder to create test data. I name it ''DB_100cities'', following the name format like the previous ones. Select Database data for the Data Type. Then, click OK. After the data file is created and opened, select Edit Query. In this Database connection and Query Settings window, we need to configure to connect Katalon Studio with our Postgres database and write the query to get the test data set.

First, fill in ''PostgreSQL'' for the JDBC driver. Copy the URL sample below for our PostgreSQL and paste it in the Connection URL section. Next, we need to replace the ''DB_NAME'' and ''SCHEMA'' components in the sample with the values in our database. Switch to the pgAdmin, here are our database name - ''postgre'' and the schema - ''public''. But let's change that to ''katalon_studio''. Then, type them in our URL sample... Press Test Connection, and it succeeds, ''Connection successfully.''

The next thing is to write the query, just like what I did earlier, ''select city, expected from db_ddt''. It will find the data according to the query and load it in. Let's save it. From here, the steps are similar to the previous lessons.

Create a test suite and add a test case. Then, move on to data binding. Add in our DB_100cities data file and press Map all. The first variable has been bound to the city column in the database (which has the same name). Meanwhile, the second variable has not since the column's name is different. I'll do this mapping manually by selecting Data column for Type, DB_100cities for Test Data. And expected for Value. Save it again and run this test suite.

According to the data order, it will run 3 times, with Atlanta, Miami, and New York. And just like the other data sources, when you need to add or change the test data, you just need to do so in the database. You don't need to change anything in the test case or test script. Let's wait for a few seconds until it's finished.

Alright, looking at the Job Progress, everything is almost done. It's preparing the report and uploading it to TestOps... Our test passed. All the execution details have been noted down here in the Log Viewer. You can download the report to your local computer and send it to others by clicking on the Result tab and selecting Export Report.

For example, I will download the HTML report for this test suite execution. You can see our test suite name here and summary information. There are 3 tests here - which are actually just 1 test case that ran 3 times with 3 different sets of data. In each test case, it displays the summary, status, executed steps, and data binding which gives you information on which test data is used. To learn more about these kinds of reports, make sure to check out our course: Katalon Studio: How to work with execution logs and test reports.

That's the end of our chapter. You've learned to apply Data-Driven Testing with different external data sources, including Excel, CSV, and now databases. Moving on to the next lesson, you will know how to combine data from different sources, check data change before running your data-driven tests, and why you should do these. See you.

Well done. You've reached the last chapter of this course where we're going to learn how to combine data from multiple sources to run data-driven tests. This is useful for large and complex projects where you need to gather many data files from different teams to run your tests.

Alright, let's create a new test suite and then add a test case that has variables. In the Test Data section, click Add to select the data source. But instead of choosing only one, I will go for both Excel and CSV data files. Click OK. Simple. But let's go for three. I'll also add the Postgre database we've created earlier. So, we have 3 data sources here.

For Variable Binding, you can use these Set Type and Set Test Data buttons here to do the mapping. For the city variable, click on Set Type and choose Data Column. Continue to select Set Test Data and choose the Excel file. For the value, pick the city column. Do the same for the other variable. Choose Data Column. For Test Data, let's go with the CSV file. And for the value, select the expectedResult column. That's it for the setup. I'll run this test suite and see how it works.

It is expected to use the Excel file for the city location input and the CSV file for verification. Particularly, in this Excel data file, it will use the values in the city column: Atlanta, New York, Miami, and Tokyo respectively to input the cities for location. And in the CSV file, it will use this expectedResult column: Stays in Atlanta, New York, Miami, and Tokyo respectively to verify the search output. Since the city order for the input and output from the two data files match each other, I expect our test run will pass. Let's wait and see.

And it's done... All of the tests passed, as expected. Click on this Result tab if you want to see or download the report for this test suite execution. Now, I'll bind the expectedResult variable to the Postgre database. Run this suite again and expect it to fail.

Let me explain. The second and third values in this Excel file's column are New York and Miami. Meanwhile, they are Stays in Miami and Stays in New York in the database's column. Since the city order does not match, our test run will fail. Let's wait and see.

So, the second test has failed. Just like we expected. It failed at step 7, the verifying step. It could not find the ''Stays in Miami'' text because the input was New York, hence the search output was actually ''Stay in New York'' on the Airbnb website. That concludes our chapter. You've learned how to combine test data from different sources to run data-driven tests. In the last lesson, we're going to see how you can use the Checkpoint feature to check data change before running tests and why you should do so.

One of the benefits of Data-Driven testing is that test data is separated from test scripts. However, in large and complex projects, the data files you use might be modified or get updated by the teams in charge. This might reduce the data integrity and cause your tests to fail at certain data-bound steps. To detect this issue and save time on test executions, you can make use of the Checkpoint feature in Katalon Studio. You'll use it to verify whether the test data is still the same as the data source before using the data to run the associated steps.

To do so, select a test case > Add a step. Type in ''Verify Checkpoint'' and use this keyword. Next, you'll need to create a checkpoint. Go to Checkpoints > New > Checkpoint. Give it a name. I'll leave it as it is. Next, choose the type. I'll go with Database Data. Click Next. Here, we'll need to configure the database connection, just like what we did. When everything is done, select Finish.

It will take the data from the database according to the query I wrote. Select the values you want to check. I'll choose all of them. This means if one piece of the selected data is changed compared to the database, the tests that use these data will fail at the Verify Checkpoint step. In real-life scenarios, you shouldn't check on all test data. Instead, only check on the key and important data to minimize the chances of test failures due to data change issues.

Next, double click on the Input of the Verify Checkpoint step. Change the value here from null to the Checkpoint we've just created. Select OK. Now, if I run this suite, nothing's gonna happen since there's no change in the database. So, I'll go on and modify it a little bit to help you see the outcome of using Checkpoints. After navigating to the data table, I'll delete the ''s'' in the ''Stays in Tokyo'' text... Don't forget to save it.

Here's a tip I usually do to save up execution time and resources whenever I need to check data change for Data-Driven Testing. If all the test steps are good and stable (you can tell from previous test runs), then put the Verify Checkpoint step at the beginning of your tests. To see what I mean, let's save and run this test suite.

Before opening a browser, it will go and check on the selected data. If there's any difference compared to the database, the verifying steps will fail, causing the tests to fail. Let's wait for a few seconds. And it's done. You can see there are 4 test failures. They all failed and stopped at the 1st step verifyCheckpoints due to the data change - ''Stay in Tokyo.'' You don't have to wait for several steps to be executed just to find out your tests failed due to this issue. This means you detect it earlier and save up execution resources.

In case you wonder why there are 8 test runs, instead of 4 like usual, it's because of my Retry settings for test failures. You don't need to care about that right now. We'll mention it in another course. Alright, congrats! You've completed this course. You've gone through everything to start applying Data-Driven Testing with Katalon Studio.

To recap, you've learned the what, why, and how of Data-Driven Testing, how to apply Data-Driven Testing using Katalon Studio with internal and external data from Excel, CSV files, and databases, combining data from multiple sources to run data-driven tests, and finally using Checkpoints to check data change before running tests.

So, what's next? Practice makes perfect! Go to Download on Katalon [dot] com, install Studio, and start applying DDT to your projects. Katalon Academy is working on even more courses to help you learn about test automation and immediately put them into practice with Katalon tools. In the meantime, you can watch more of our existing courses by clicking on the Courses button right on the top menu bar. Thank you, and happy learning!