Using Data Map for Dynamic Test Data Management – ACCELQ

Data Map is a framework library in ACCELQ that streamlines the storage, management, and sharing of test data during execution. It includes commands to share data between different steps within a test case or across multiple test cases in a job.

Understanding Scope in Data Map

Data Map supports two scopes for storing test data during execution:

Test Case Scope
- Values are accessible only within the same test case
- Data is automatically cleared when test case ends
- Each test case has its own isolated storage
- Perfect for test-specific data that shouldn't leak to other tests
Global Scope
- Values are accessible across all test cases in a job
- Persists throughout the job execution
- Shared among all test cases
- Useful for common configuration or shared test data

⚠️ Critical Notes on Data Sharing in Global Scope:

Parallel Execution: When test cases run in parallel, there's no guaranteed order of execution. A test case trying to access global data may run before the test case that creates that data. Always design your tests considering this limitation.
Distributed Execution: ACCELQ supports distributed job execution where a test job can be distributed across multiple Agents running as independent sub-jobs. In such scenarios:
- Global scope is limited to the individual sub-job only
- Data is not shared across different Agents

Commands Reference

1. Store Value in Data Map

With key 'userID', store value '12345' in test case scope of Data Map

Stores a value against a key
Overwrites existing value if key already exists
Validates storage limits before saving

2. Get Value from Data Map

Get value for key 'userID' from test case scope of Data Map

Retrieves stored value for given key
Returns empty string if key doesn't exist
Provides warning message for non-existent keys

3. Check Value Exists in Data Map

Check if key 'userID' exists in test case scope of Data Map

Returns true/false based on key existence
Useful for conditional logic in test cases

4. Remove Key from Data Map

Remove key 'userID' from test case scope of Data Map

Removes single key-value pair
No effect if key doesn't exist
Provides warning message for non-existent keys

5. Clear Data Map

Clear all values from test case scope of Data Map

Removes all stored values from specified scope
Use with caution - operation cannot be undone

6. List Keys from Data Map

List keys from test case scope of Data Map

Returns List collection of all stored keys
Result can be parsed using ACCELQ’s List Collection command set
Useful for debugging and verification

⚠️ Note: Keys in Data Map are case-sensitive. For example, 'UserID', 'userId', and 'USERID' are treated as different keys and can store different values.

Storage Limits

To ensure optimal performance and resource usage, Data Map implements the following limits:

Maximum key length: 256 characters
Maximum value size: 5MB per entry
Maximum total storage per test case: 50MB
Maximum total storage for global scope: 200MB
Maximum keys per test case: 1,000
Maximum keys in global scope: 5,000

Example Use Cases

1. Multi-Step Process with State

// Step: Store order ID
Store value in Data Map with key 'orderID', value 'ORD-2024-001' in test case scope
...
// Step: Add items to order
Store value in Data Map with key 'orderItems', value '["item1","item2"]' in test case scope
...
// Step: Verify order
Get value for key 'orderID' from test case scope of Data Map
Get value for key 'orderItems' from test case scope of Data Map

2. Shared Configuration

// Step: Store global config
Store value in Data Map with key 'apiEndpoint', value 'https://api.example.com' in global scope
...
// Step: Use in any test case
Get value for key 'apiEndpoint' from global scope of Data Map

Comparison with Primary Data Sharing Approaches

ACCELQ provides three approaches for data sharing, each with distinct use cases:

Parameter Linking (Most Preferred for Step-to-Step Sharing)

Specifically designed for sharing data between steps within the same test case
Direct linking between step outputs and inputs
Provides the clearest visualization of data flow in the business process view of the Scenario
Makes data dependencies immediately visible in the test scenario
Enables better maintenance and debugging through visual traceability
Should be your default choice for any step-level data sharing
Learn more about Parameter Linking

Run Properties (Preferred for Cross-Test Case Sharing)

Specifically designed for sharing data between different test cases
Provides visual representation of data flow and dependencies across the test suite
Recommended for simple key-value data sharing between test cases
Excellent for maintaining data flow visibility across test cases
Learn more about Run Properties

Data Map (Alternative Approach - Use Sparingly)

Provides dual scope functionality but with less visibility:
- Test Case scope serves the same purpose as Parameter Linking
- Global scope serves the same purpose as Run Properties
However, both scopes lack the transparency and visual data flow of primary approaches
Best for handling large datasets and complex data structures (JSON etc.)
Useful when Parameter Linking or Run Properties become unwieldy
Consider only when primary approaches don't meet requirements due to data complexity

⚠️ Note: None of these approaches support cross-Agent data sharing in a Distributed job setup.

💡 Important: Both Parameter Linking and Run Properties provide superior business process management in automation by making data flow visible and maintainable within their specific use cases. While Data Map offers flexibility through its dual scopes, it inherently hides the data flow in the logic. Always evaluate if the specialized approaches can meet your needs before opting for Data Map.

Best Practices

1. Prefer Run Properties where feasible

Consider Run Properties for standard business process requirements
Use Parameter Linking as preferred mode to share data between test steps
Use Data Map only when dealing with complex data structures
Document data dependencies for ease of maintenance

2. Scope Management

Use test case scope by default
Only use global scope when data truly needs to be shared across different test cases
Be cautious with global scope in parallel execution
Remember that global data might be modified by any test in the current job
Don't rely on data sharing across Agents in distributed execution. Design tests to be self-contained within an Agent.

3. Key Naming and Validation

Use descriptive, meaningful key names
Consider adding prefixes for better organization
Document key names and purposes in test documentation
Always handle cases where keys might not exist
Always check if key exists before critical operations

4. Performance and Resource Management

Monitor storage usage in long-running tests
Avoid storing large datasets when possible
Clear data maps when no longer needed
Remember that test case scope data is cleared up at the end of each test case

5. Data Structure and Organization

Use structured data formats (like JSON) for complex data, to store as "values"
Don't use global scope for test-specific data
Be careful with timing in parallel test execution
Don't assume order of execution when using global scope