API Configuration File | Bondar Academy
Course: Playwright API Testing with TypeScript
Module: Building a Framework
Instructor: Artem Bondar
Lesson Summary
In this lesson, we explore how to create a configuration file to manage various variables within our testing framework efficiently. This approach centralizes values, making it easier to maintain and update them across multiple tests. Key Concepts Centralized Configuration: Instead of hardcoding values like email credentials and base URLs in multiple places, we create a single configuration file. File Creation: A new file named apitest.config.ts is created to store all configuration variables. Configuration Object: We define a constant config as an object to hold our variables, such as APIURL , userEmail , and userPassword . Using the Configuration To utilize these values in tests: Import the configuration file in the test or create a fixture that imports it. Access variables using config.userEmail and config.userPassword in the test files. Environment Management We can also manage different test environments (e.g., dev, QA, prod) by: Using process.env to read environment variables from the command line. Creating logic to switch credentials based on the selected environment. Logging the current environment to the console for visibility. Command Line Usage To run tests in different environments, use: testenv=dev npx playwright test smoke test.spec.ts For Windows, the command differs: set testenv=QA && npx playwright test smoke test.spec.ts In summary, we established a centralized configuration system that simplifies managing static values and supports switching between different test environments seamlessly.
Video Transcript
Alright guys, I promise this lesson will be easier. So in this lesson we're going to talk about how to create a configuration to manage different variables inside of our framework in a single place. So let's jump into it. So far inside of our framework we have few variables. For example, we have test credentials for email and password directly inside of the code. Also we have base URL inside of the fixture right here. Well, this is not really a right place to keep those values. So think about it. If you have more spec files, more tests like this, you will need to copy paste those values from test to test. That's the first thing. The second thing, you might have more different API URLs and more different variables that will be needed for your test execution. And if you keep it directly inside of the code, it's gonna be a mess. So it's better to keep those values somewhere in centralized placed as it's central as the ultimate source of truth. So let's do this. Inside of the root of the framework, let's create a new file which I call apitest.config.ts. This will be a file to keep all the configuration and I create a new constant which I call config. So simple. This will be an object and then I will return this configuration file export config like this. Now we can put here all the variables that we want to use in the test. So let's start with what we have, base URL. So let's call it API URL and we provide the value of our API URL like this. Then second value we need, what is user email? User email will be this one. We're gonna put it right here. And the third value is user password. And the password is this one. Now how to read those values? Now there are two options. You can just directly import this file inside of the test and inside of the fixture or for the test level, you can create a fixture that will be responsible for importing that configuration file. Let's do this way, okay? But if you need the configuration file somewhere else, you can import it as a file. But for the test, we will import it as a fixture, just the right playwright approach. So going back to fixture and first, let's figure out with this base URL. Let's import our configuration file, import config from API test config like this. And then instead of using base URL right here, we can call config.APIURL, that's it. Now we can remove this guy from here. And since we are in the fixture file, let's quickly create the fixture for the configuration file as well. So I create a new fixture which I call config. And it will be just a very, very, Function like this. And it should be a sync. And we call inside of the function a wait use that will return the config, right? So it's highlighted in the red squigglies because we need to define the type option for this fixture as well. Which is config type of config. All right, this one is fixed. And now we can use config inside of the spec file. So here next to the API, I add a second config fixture. And we can use this config fixture over here. So I call config.userEmail. And also instead of welcome, I use config.userPassword, like this. So now we're reading the credentials from the configuration file. And we centralize all the values needed to run our test in this simple config object. So let's run to see if it is working, running the test. And test pass successfully. Okay, so what else you can do with this configuration file over here? So let's say that you have several test environments for your test application, dev environment, QA environment. And you want to switch between the environments. And also you want to be able to switch between environments using the command line interface. So how would you do that? And we will talk about environment variables a little bit later. This is just an introduction how you can switch between environments using the configuration over here. So first of all, let's add a new constant that I call process env equals to. And I will call internal Node.js process, which is called process.env. And then the name of the environment variable through the command line that I want to allocate to pass my variable. For example, I call it test underscore env, something like this. And then I will create constant env, which I will assign result of this process env as a default value. Or if this value is not provided, I will, let's say, assign the dev environment as my default environment, for example. And then now using this flag, you can switch between the environments. For example, you can create a very simple logic, something like this. If env equals to, for example, QA, then let's say you should have a different set of the credentials. And we need to add config.userEmail, config.userPassword. And instead of colon, we have to use equal. So we reassign the value to the values inside of the default object with the new values. And let's say that you have a different environment, which is, let's say, I don't know, prod environment like this. And you have some other credentials for the prod environment. Now what you have is, if you want to run your test, for example, in QA, you change this to QA, this flag. This flag automatically becomes the QA environment. And when the test is executed, it will read these credentials instead of these default credentials. Or you say, for example, prod environment, and it's going to work like that. Or if you pass this flag through the command line, then the value through the command line will be used for the environment. And one more thing, just for the better visibility, let's add to the console.log some message, what environment was used. Something like this, console.log, testEnvironmentIsEnvironmentIs, and the environment is environment. It will be just printed to the console like this. And let me demonstrate how it's gonna work. So I have a several test account, and I, for example, use pwtest at test.com, and the password for this guy will be welcome2. So that's the second account. And let's try to run the test using different accounts. So to know that it worked, let me console.log, and I will print the object of token user, this one. So we will see which token was used. So for example, I'm running the test. We can see the environment is dev, and currently we use pwapi-user-at-test.com. Then I, let's say, switch to QA environment like this, and run this test one more time. And now we were using a different account for the QA environment. So this is how you can switch. And also, if you want to use a terminal to switch between the accounts, you can type this command. So environment variable is this one, testenv. So I type testenv equals to, for example, dev, and then run npx playwright test, and then the name of the spec file, smoke test.spec.ts. I run the test, and the test is executed. So for test pass, you can see the dev environment was used, and the dev email for the dev environment was used to run the test. And if I run the same command to use a QA environment like this, I switch to QA, run it, and now a different account was used to run the same set of tests. We can see it's printed out in the console log. All right, so if you use Windows, for Windows, there will be a different command because this type of the syntax is available only for Mac and for Linux. So for Windows, if you use command prompt, the command will be set. So let me do like this. So command would be set testenv QA, and then double ampersand, and end, and then you run command. And this command will set a process environment variable and execute the test for the Windows. If you use command prompt, this is important. All right, so I believe that's it. And let's quickly summarize what we did in this lesson. To manage a different static values that you will need for your framework, such as different API URLs, different accounts, maybe IDs or something like this, we created apitest.config.ts. We created a default object as a config. And if you want to switch between the test environments, you can override those values using this simple syntax. We also can read the value for the environment variable from the process environment variable that you can pass through the command line. And if you want to switch between environments when you run tests locally on your computer, you just simply change this value from QA, dev, prod, and so on. And this value will be automatically picked by the framework. We also created a custom fixture that reads this configuration file. And now this config can be used inside of the any spec files as a regular fixture right here. And then you can use configuration options inside of the test. All right, that's it, guys, and see you in the next lesson.