Dynamic Test Data Management for Realistic Test Scenarios: TDM (Test Data Management)

• Test reliability improves with stable data.
  When using clean, consistent data tailored to scenarios, test results become more accurate and reliable.
• Solves the problem of user creation and data preparation.
  Instead of manual effort, TDM enables fast, automated, and correct user generation.
• Provides data suitable for test scenarios.
  Users with gold accounts, balances, unverified emails, etc., can be created to fit specific test cases.
• Offers a shared infrastructure for both automation and manual tests.
  The same users can be used across automated and manual testing teams, eliminating inconsistencies.
• Benefits developers, analysts, and QA teams.
  Test data is a shared necessity; TDM provides a centralized solution for all roles in the software lifecycle.
• Takes test data preparation out of testers’ hands and systematizes it.
  Data preparation workload is handled automatically via APIs, reducing time and risk of errors.
• Prevents most “flaky” tests.
  Tests accessing the right data at the right time produce fewer failures, especially reducing repeated failures in CI/CD pipelines.

Analysis and Infrastructure Requirements for the TDM Project

1. Database Connections

• The application under test may connect to multiple databases.
• These databases can be of different types (PostgreSQL, MSSQL, MySQL, etc.).
• The TDM system must be configured to work compatibly with all these databases.
• Dedicated connection configurations for each data source allow test data generation and updates on the desired database.

2. Service and Domain Management

• The application may call multiple domains (service endpoints).
• TDM should centrally manage domain information.
• Keeping service URLs in .yaml files is useful:
• This enables automatically routing requests to the correct domain depending on the test environment.

3. Environment Definitions

• Multiple runtime environments may exist: test, dev, uat, prep, prod, etc.
• Each environment may have different service domains and database connection details.
• Environment-specific definitions should be maintained in .yaml files:
• Service URLs
• Database connection info
• This way, the TDM project can be configured for each environment, making switching effortless.

4. Access via Swagger

• Services in the TDM project can be easily tested via the Swagger UI.
• Swagger allows:
• Viewing the purpose of each service
• Seeing required request parameters, descriptions, and valid values
• Switching between different environments, e.g., from dev to uat

Swagger Usage Recommendations:

• Each endpoint should have brief descriptions.
• Request parameter explanations and example values should be added to Swagger docs.
• Environment selection option (e.g., via an env parameter) should be provided.

Best Practices for Using the TDM Project Efficiently

Why Creating a New User for Every Test Case Is Not Ideal

Creating a new user for each test case quickly clutters the database, causing performance issues and difficult data management.
Instead, create a customer reference table. Tests can then use a getCustomer service to fetch existing prepared users instead of generating new ones. This ensures:

• The database remains clean
• User data is reusable
• Test speed and stability improve

Data Security and Access Control

Since multiple teams might use the getCustomer service and may accidentally modify data, enforce:

• Access restricted only to test automation teams
• A fixed, secure Authorization token for accessing the API
  This ensures that test data is managed only by authorized test processes, preventing unwanted data manipulation.

Backup Mechanism for CreateCustomer Service Failures

The createCustomer service might fail due to DB connection issues, query errors, service downtime, or timeouts, causing unrelated test failures. To handle this:

• Create a disaster_customer backup table.
• Preload it with backup users for test usage.
• If createCustomer fails, TDM falls back to users from this table, avoiding flow interruptions.

Preventing User Collisions with in_used Flag

Users fetched via getCustomer should not be used concurrently in multiple tests. For this:

• Add a boolean in_used flag to user records.
• When a user is fetched, set in_used = true.
• After the test finishes or after a timeout, reset in_used = false.
  This prevents user collisions across tests.
  Same applies to the disaster_customer table, where in_used = true users should be cleaned regularly.

Managing User Types with user_type

Instead of manipulating users repeatedly, define pre-set user types for common test scenarios.

• Classify users by user_type (e.g., gold_account, verified_email, low_balance).
• Both database and createCustomer service consider this parameter to generate or retrieve appropriate users.
• This streamlines user provisioning and shortens test turnaround time.

Benefits of This Approach

• Reduces database clutter
• Increases test stability
• Ensures secure and controlled data access
• Makes the system resilient to service/database errors
• Manages user diversity to expand test coverage

TDM Project Architecture and Directory Structure

A modular, readable, and maintainable codebase is ensured through a layered architecture and clean project structure as shown below:

├── src
│   ├── main
│   │   ├── java                      
│   │   │  ├── api
│   │   │  │  ├── controller       
│   │   │  │  │  ├── impl       
│   │   │  │  │  ├── spec       
│   │   │  │  ├── request       
│   │   │  │  ├── response       
│   │   │  ├── config
│   │   │  ├── domain
│   │   │  │  ├── constant  
│   │   │  │  ├── service
│   │   │  │  │  ├── impl   
│   │   │  │  │  ├── input   
│   │   │  │  │  ├── output   
│   │   │  │  │  ├── spec   
│   │   │  ├── entity
│   │   │  ├── mapper
│   │   │  ├── props
│   │   │  ├── repository
│   │   │  ├── util
│   │   ├── resources
│   │   │  ├── application.yaml
├── pom.xml
└── README.md

Folder and Package Descriptions

1. api/

The layer communicating with the outside world. Contains REST endpoints and API-related classes.

• controller:
  Classes handling API requests.
• impl: Controller implementations
• spec: API specifications, Swagger definitions, or interfaces
• request:
  Data models used in incoming API requests (DTOs).
• response:
  Data models returned by the API.

2. config/

General configuration classes (Spring beans, security settings, profile-based configs).

3. domain/

Central package for business logic. Contains domain-focused classes and services.

• constant:
  Project-wide constants (enums, static variables).
• service:
  Service layer implementing business rules.
• impl: Service implementations
• input: Input models to services
• output: Output models from services
• spec: Service specifications or interfaces

4. entity/

Database table mappings (Entity classes). Mapped using ORM tools like JPA/Hibernate.

5. mapper/

Classes converting between entities and DTOs (request/response).

6. props/

Helper classes for properties, constants, and configuration data.

7. repository/

Database operation layer. Defines CRUD operations via Spring Data JPA or similar libraries.

8. util/

Utility/helper classes and functions used across the project.

9. resources/

Contains configuration files (application.yaml), static resources, and other assets.

Other Files

• pom.xml: Maven project configuration file, manages dependencies and build settings.
• README.md: General project information, setup instructions, and usage guidelines.

Exp. Swagger

Spring Boot Infrastructure and Maven Configuration

The TDM (Test Data Management) project is built as a modern Java application using the Spring Boot framework. Thanks to its ease of configuration, robust plugin ecosystem, and widespread adoption, Spring Boot is an ideal choice for projects of this nature.

The project includes the following components and libraries:

Core Spring Boot Components

• spring-boot-starter-web: For creating REST APIs
• spring-boot-starter-data-jpa: For managing database operations
• spring-boot-starter-actuator: For application health checks and monitoring
• spring-boot-starter-log4j2: A powerful logging framework
• springdoc-openapi: For Swagger-based API documentation
• spring-boot-starter-test: Essential components for testing

Other Key Libraries

• MapStruct: For transforming between Entities and DTOs
• Lombok: To eliminate boilerplate code
• Micrometer + Brave: For tracing and observability
• PostgreSQL + MSSQL JDBC Driver: Supporting multiple database types
• Kafka Log4j Appender: For sending logs to Kafka

### 🔗 Sample Project

You can find a sample project related to the TDM (Test Data Management) system at the GitHub repository below:
👉 https://github.com/dogangunemre/test-data-management