Introduction

One of the most common mistakes in Selenium automation is placing test data directly inside the test script. While hardcoded values may work for small examples, they make automation difficult to maintain as the project grows.

Hardcoded Test Data refers to input values such as usernames, passwords, URLs, search terms, or form data that are written directly into the automation code. Whenever these values change, the test script must also be modified.

A better approach is to store test data in external files such as JSON, CSV, Excel, YAML, databases, or environment variables. The test script simply reads the required data from these external sources, making it reusable and easier to maintain.

In this tutorial, you’ll learn why hardcoded test data should be avoided and how to use external JSON files for managing test data.

What is Hardcoded Test Data?

Hardcoded test data means writing test input values directly inside the automation script.

For example:

driver.find_element(By.ID, "user-message").send_keys("Hello World")

Here, the value “Hello World” is permanently written into the test.

If the input value changes, the automation code must also be modified.

Why Avoid Hardcoded Test Data?

Avoiding hardcoded values provides several benefits:

Makes test scripts reusable.
Simplifies maintenance.
Supports data-driven testing.
Allows multiple test data sets.
Separates test logic from test data.
Improves framework scalability.
Reduces code duplication.

Better Approach: External Test Data

Instead of writing values directly into the test, store them in external files such as:

JSON
CSV
Excel
YAML
Database
Environment Variables

The automation script reads the required values at runtime.

Example

import json

from selenium import webdriver
from selenium.webdriver.common.by import By


def test_avoiding_hardcoded_test_data(tmp_path):
    data_file = tmp_path / "form_data.json"
    data_file.write_text(
        json.dumps({"message": "External Data"}),
        encoding="utf-8"
    )

    data = json.loads(data_file.read_text(encoding="utf-8"))

    driver = webdriver.Chrome()

    try:
        driver.get("https://www.testmuai.com/selenium-playground/simple-form-demo")

        driver.find_element(By.ID, "user-message").send_keys(data["message"])
        driver.find_element(By.ID, "showInput").click()

        assert driver.find_element(By.ID, "message").text == data["message"]
    finally:
        driver.quit()

Understanding the Code

Import Required Modules

import json

from selenium import webdriver
from selenium.webdriver.common.by import By

The required modules are imported.

json is used to create and read JSON data.
webdriver launches the browser.
By locates web elements.

Create the Test Function

def test_avoiding_hardcoded_test_data(tmp_path):

A PyTest test function is created.

The tmp_path fixture creates a temporary directory that is automatically cleaned up after the test finishes.

Create the JSON File

data_file = tmp_path / "form_data.json"

data_file.write_text(
    json.dumps({"message": "External Data"}),
    encoding="utf-8"
)

A temporary JSON file named form_data.json is created.

The JSON file stores the message:

{
    "message": "External Data"
}

In real automation frameworks, JSON files are usually created in advance and stored inside a dedicated testdata folder rather than being generated during test execution.

Read the JSON Data

data = json.loads(data_file.read_text(encoding="utf-8"))

The JSON file is read, and its contents are converted into a Python dictionary.

The value can now be accessed using:

data["message"]

Launch the Browser

driver = webdriver.Chrome()

A new Chrome browser session is launched.

Open the Webpage

driver.get("https://www.testmuai.com/selenium-playground/simple-form-demo")

The browser navigates to the Selenium Playground Simple Form Demo page.

Enter the External Test Data

driver.find_element(By.ID, "user-message").send_keys(data["message"])

Instead of hardcoding the message inside the script, the value is read from the JSON file.

This allows the same automation script to run with different test data without changing the code.

Click the Button

driver.find_element(By.ID, "showInput").click()

The Show Message button is clicked.

Verify the Result

assert driver.find_element(By.ID, "message").text == data["message"]

The displayed message is compared with the value loaded from the JSON file.

Close the Browser

finally:
    driver.quit()

The browser is closed after test execution.

Hardcoded Data vs External Test Data

Hardcoded Test Data	External Test Data
Stored inside the test script	Stored in separate files
Difficult to maintain	Easy to maintain
Requires code changes when data changes	Only the data file needs updating
Limited reusability	Highly reusable
Not suitable for data-driven testing	Ideal for data-driven testing

Practical Example

Suppose an application needs to test 500 different customer names.

Using hardcoded values would require modifying the script repeatedly.

Instead, the customer names can be stored in a JSON or Excel file, allowing the same test script to execute for every data set without changing the code.

Automation Testing Example

Consider an online shopping application.

Instead of hardcoding product names inside the automation script, all product details are stored in an external JSON file. During execution, the framework reads the product information and performs the search automatically. Adding new products only requires updating the JSON file, not the test script.

Real-World Example

External test data management is commonly used in:

Banking applications
Healthcare systems
E-commerce platforms
CRM applications
ERP systems
Government portals
SaaS products
Enterprise Selenium automation frameworks

Advantages of Avoiding Hardcoded Test Data

Improves code reusability.
Simplifies maintenance.
Supports data-driven testing.
Keeps test logic separate from test data.
Makes it easy to test multiple scenarios.
Reduces duplicate code.
Improves framework scalability.

Common Mistakes Beginners Make

Hardcoding Input Values

Avoid writing values such as usernames, passwords, or messages directly inside Selenium scripts.

Mixing Test Logic with Test Data

Keep the automation logic separate from the data by using external files.

Storing Sensitive Information in Code

Do not hardcode confidential information such as passwords or API keys.

Use environment variables or secure configuration files instead.

Editing Test Scripts for Every New Test Case

When new test data is needed, update the external data file instead of modifying the automation code.

Using Only One Data Source

Modern automation frameworks often support multiple external data sources such as JSON, CSV, Excel, YAML, and databases.

Choose the format that best fits your project’s requirements.

Best Practices

Store test data in external files instead of hardcoding it.
Separate test logic from test data.
Use formats such as JSON, CSV, Excel, or YAML.
Use environment variables for sensitive information.
Design tests so they can run with multiple data sets.
Organize test data inside a dedicated testdata folder.
Keep test data easy to update without modifying the automation code.

Conclusion

Avoiding hardcoded test data is an essential best practice for building scalable Selenium automation frameworks. By storing input values in external files such as JSON, CSV, Excel, or databases, automation engineers can create reusable, maintainable, and data-driven test scripts. This separation of test logic and test data makes the framework more flexible and easier to maintain as applications evolve.

Frequently Asked Questions (FAQs)

What is hardcoded test data?

Hardcoded test data refers to input values written directly inside the automation script instead of being stored externally.

Why should hardcoded test data be avoided?

It makes test scripts difficult to maintain, reduces reusability, and requires code changes whenever test data changes.

Which external files are commonly used for test data?

Common formats include JSON, CSV, Excel, YAML, databases, and environment variables.

Why is JSON commonly used for test data?

JSON is lightweight, easy to read, supports nested data structures, and is widely used in automation frameworks.

Where should test data be stored in a Selenium framework?

Test data should be stored in a dedicated folder, such as testdata, separate from the automation scripts.

Key Takeaways

Avoid hardcoding test data inside Selenium scripts.
Store input values in external files such as JSON, CSV, Excel, or YAML.
Separate test logic from test data to improve maintainability.
External test data supports reusable and data-driven automation.
Organizing test data properly helps build scalable and professional Selenium automation frameworks.