Data-driven testing replaces constant values with variable values drawn from a data source. Test steps are repeated once for each row of data in the source, allowing you to test multiple scenarios without rewriting test scripts.
Key Components
Data-driven testing has three main components:
- Variables - which need to be defined
- Data sources - containing your test data
- Data bindings - which connect the variables to the data sources
Benefits of Data-Driven Testing
- Makes it easy to add or change test scenarios by simply modifying test data
- Ensures inputs are done exactly as specified in the test data
- Compares to correct expected results (which can also be data-driven)
- Executes much faster than manual tests
- Frees testers from repetitive data entry for more challenging exploratory testing
- Useful for functional UI testing, positive and negative test cases
- Tests corner, edge, and boundary cases
- Allows testing subsets of production data
- Simulates data entry for performance and load testing
- Can populate test or production databases
Step 1: Defining Variables
Variables are the foundation of data-driven testing. There are several types of variables you can define:
Action Variables
Action variables replace constant values in your test actions.
How to Create Action Variables:
- Open the recording module (e.g., "Insert Name")
- Select the dropdown list next to the constant value you want to change
- Click As New Variable
- Give the variable a meaningful name (e.g., txtFirstName)
- Set a meaningful default value (used when no data source is available)
- Click OK and save
Example: For a database entry form, create variables for:
- First Name (txtFirstName)
- Last Name (txtLastName)
- Age (txtAge)
Repository Variables
Repository variables replace a certain part of an item's Ranorex path - the defining attribute with a variable.
How to Create Repository Variables:
- Open the recording module
- Right-click on the appropriate action
- Select Make Repository Item Variable
- Ranorex file opens - click the variable symbol
- Enter a name for the variable (e.g., lstDepartment)
- Click OK and Apply
- The variable now appears in the item's RanPath in the repository
Example
- Dropdown menu selections (Department, Gender)
- Radio button selections
- Dynamic UI elements
Validation Variables
Validation variables are used for dynamic validation steps.
How to Create Validation Variables:
- Open the appropriate recording module containing validation
- Right-click and select As New Variable
- Give the variable a meaningful name
- Click OK
Example
Create variables to validate database counter updates as entries are added.
Managing Variables
For Action or Validation Variables
- Open the recording module where they are defined
- Click Variables to manage them
For Repository Variables:
- Click Variables in the Repository view
- A dialog box will open where you can manage your variables
Step 2: Managing Data Sources
Data sources contain the test data and are managed per test suite. Once added to a test suite, the data source can be assigned to test containers within that suite.
Simple Data Table
Creating a Simple Data Table
- Click Manage Data Sources
- Select New Simple Data Table
- Name the table and press OK
- Right-click on test case and select Data Source
- Select your simple data table
- Enter the required data directly into the table
- Click OK when finished
Excel and CSV Data Sources
Adding Excel/CSV Data Sources
- Click Manage Data Sources
- Select Add New Excel Connector (same process for CSV files)
- Name the data source
- Select the Excel file and press Open
- Click OK
- To assign to a test container, use the context menu and select Data Source
- Select your file - the data will load
- Press OK
Data Management Features
Data Masking
- Click Manage Data Sources
- Select any columns you want to mask
- In reports, masked information will be starred out for security
Limiting Data Range
- Right-click on the test container
- Click Data Source
- Tick Range and enter the range you wish to include (e.g., "1 through 6")
- Press OK - your data source will now be filtered
Step 3: Data Binding
Data binding connects your defined variables to your data source columns.
Manual Data Binding
How to Bind Variables
- Right-click on any unbound variable
- Select Data Binding
- A dialog box appears detailing data columns and module variables
- Specify one variable per column:
- Column "txtFirstName" → Variable "txtFirstName"
- Column "txtLastName" → Variable "txtLastName"
- Continue until all columns are bound to corresponding variables
- Click OK
Auto Bind Feature
Using Auto Bind
- Start with all variables unbound
- Use the context menu to bind variables
- When the dialog box opens, click the Auto Bind button
- Columns automatically bind to their corresponding variables
Step 4: Running Data-Driven Tests
Basic Test Execution
Running Your Test
- Ensure you have:
- Defined your variables
- Assigned your data source
- Bound variables to data source
- Click Run
- Ranorex Studio uses the data source to enter all rows into the demo app
- The test iterates once for each data row
Example
If your data source has 8 rows, the test case will run 8 times total.
Deployment Considerations
For Excel Connectors
- Target machine doesn't need Excel license installed
- Install Microsoft Access Database Engine Redistributable 2013 on target machine
- Test can then run via xcopy or Ranorex Agent
Configuration Options
Excel Execution Configuration
- Open the solution settings file
Insert the following code structure:
<testing> <data> <Excel> <dataLoadingPreferences>[OPTION]</dataLoadingPreferences> </Excel> </data> </testing>
Available Options
- PreferExcel - Uses Excel if available, or uses OleDB if Excel unavailable
- PreferAceOleDB - Uses OleDB if available, or Excel if not available
- RequireExcel - Uses only Excel
- RequireAceOleDB - Uses OleDB only
Step 5: Using Parameters
Parameters are the simplest kind of data source - essentially a data source with only one row. They're useful for keeping modules reusable and tests maintainable, and allow you to pass variable values from one recording module to another.
Types of Parameters
Global Parameters: Added to the test suite item (available across all test containers) Local Parameters: Added to test containers (available within that container)
Creating and Using Parameters
Defining Parameters for UI Navigation
- Create the Variable
- Double-click on the Start AUT recording module
- Select the mouse click action
- Right-click and select Make Repository Item Variable
- Enter the name (e.g., "selectRegister")
- Close and save
- Bind the Variable
- Use the context menu and select Data Binding
- Name the parameter
- Insert the exact value (e.g., "selectRegister")
- Select selectRegister and click Apply and OK
- Repeat for Additional Test Cases
- For second test case, give different value (e.g., "testDatabase")
Passing Values Across Modules
Example Scenario: Logging database entry counts
Setup
- Extract Value and Write to Variable
- Open recording module Get DB Counter
- Add a Get Value action
- Link to repository item DB Counter
- Create new variable named "varCounter" with default value of zero
- Log Counter Value to Report
- Open recording module Write Max Count to Report
- Add new log message
- Click As New Variable
- Name variable varWriteCounter
- Set default value to zero
- Create Transfer Parameter
- Click the test suite
- Use context menu and select Global Parameter
- Name it appropriately and press OK
- Link Variables to Parameter
- Right-click Add Person to DB test case
- Select Data Binding
- Bind the parameter to the varCount variable
- Click Apply and OK
- Repeat for the varWriteCount variable
Step 6: Using Conditions and Rules
Conditions allow you to control which data rows are processed during test execution based on specific criteria.
Setting Up Conditions
Basic Condition Setup
- Select the test case
- Right-click and select Condition
- A dialog box appears
- Select Add Rule
Configuring Rules
Rule Configuration Options
- Multiple Rules: Select whether to run test if "All" or "Any" rules are matched
- Data Source: Choose which specific data source to use
- Column Selection: Select the column from data source or row from parameter
- Comparison: Choose whether value must be "Equal" or "Not Equal"
- Control Value: Enter the value to compare against
Example
To test only female entries:
- Select data source column Gender
- Set comparison to Equal
- Set control value to Female
- Click Apply then OK
Multiple Rules
You can add multiple rules at this stage for more complex filtering logic.
Test Results with Conditions
When you run the test with conditions:
- Only entries matching your condition criteria will be tested
- Results show successful entries and blocked entries
- Blocked entries are those where the condition was not met
Example Result: With 8 total entries and a Female only condition:
- 4 entries might be successful (female entries)
- 4 entries might be blocked (male entries that don't meet the condition)
Best Practices and Tips
The “Auto-load when test suite opens” Setting
What the Setting Does
The Auto-load when test suite opens option ensures that the specified test data source (such as an Excel file, CSV, or database connection) is automatically loaded into the test suite as soon as the suite is opened in Ranorex Studio. This makes all bound data immediately available for editing, preview, and data-driven test execution without requiring manual refresh or reload.
When and Why to Use It
- During Test Development: Enabling auto-load allows immediate access to test data for editing and verification, facilitating efficient design and debugging of data-driven test cases.
- For Data Sharing Between Test Cases: In scenarios where one test case writes or updates data in an external data source (for example, saving values to a spreadsheet), and subsequent test cases need to consume this updated data, auto-loading ensures the latest data is available without manual intervention. This streamlines workflows where test cases depend on dynamic data produced during the test run.
- To Catch Data Issues Early: Auto-loading helps detect problems such as missing columns or type mismatches before test execution, reducing runtime errors.
When You Might Disable It
- If the data source is very large or remote and causes delays in opening the suite.
- When data is only needed during actual test execution rather than design time.
This feature enhances the robustness and maintainability of data-driven testing by ensuring that test data is both current and accessible as needed throughout the test lifecycle. If you would like, I can assist with best practices for managing data-driven tests or setting up interdependent test cases using external data sources.
Variable Management
- Use meaningful variable names that clearly indicate their purpose
- Always provide meaningful default values for variables
- Group-related variables logically
- Keep variable names consistent with data source column headers for auto-binding
Data Source Organization
- Structure your data sources with clear, descriptive column headers
- Include both positive and negative test scenarios in your data
- Use realistic test data that represents actual use cases
- Consider data masking for sensitive information in reports
Test Design
- Design modular, reusable recording modules
- Use parameters to make tests maintainable across different environments
- Implement proper validation variables to verify expected results
- Use conditions to focus testing on specific data subsets when needed
Performance Optimization
- Filter data ranges when you don't need to test all data rows
- Use appropriate data source types (CSV for simple data, Excel for complex scenarios)
- Consider the target deployment environment when choosing data connectors
Troubleshooting Common Issues
Variable Binding Problems
- Ensure variable names exactly match data source column headers for auto-binding
- Check that variables are properly defined before attempting to bind
- Verify data types are compatible between variables and data sources
Data Source Issues
- Confirm file paths are accessible to the test environment
- Verify data source format and structure
- Check that required data connectors are installed on target machines
Condition Logic Problems
- Test condition logic with small data sets first
- Verify condition values exactly match data source values (case-sensitive)
- Use simple conditions before implementing complex rule combinations
Summary
Data-driven testing in Ranorex Studio follows this workflow:
- Define Variables (Action, Repository, Validation)
- Create Data Sources (Simple tables, Excel/CSV files, SQL databases)
- Bind Data (Manual binding or auto-binding)
- Configure Parameters (For reusability and value passing)
- Set Conditions (To filter test execution)
- Run Tests (Automated execution across all data rows)
This approach enables comprehensive test coverage with minimal code duplication, making your test suites more maintainable and efficient while providing thorough validation across multiple scenarios.