CSV Data Set Config, Parameterization, Unique Data, and Test Data Strategy: Configuration, Design Patterns, and Trade-Offs

1. Mandatory path remains local and synthetic

2. Single shared file versus generated data

A hybrid is often best: pre-generate deterministic base records, then append a non-secret run identifier if the target requires each execution to look new.

3. Choose sharing mode from cursor ownership

4. Recycle versus Stop Thread at EOF

Make reuse policy explicit:

• Reusable account: recycle can be acceptable if the same owner is allowed to reuse it.
• One-time coupon/registration ID: Recycle=false; Stop Thread=true is safer when data exhaustion should end activity.
• Data shortage is a test setup error: preflight row count and fail before load rather than discovering EOF mid-run.

<EOF> is valuable diagnostic evidence but should not be the normal production workload path.

5. Pre-sharded versus runtime-generated uniqueness

Pre-sharding makes engine ownership obvious and debuggable: shard A contains one range, shard B another, and hashes prove deployment. Runtime-generated UUIDs can avoid CSV exhaustion but make exact replay and collision audit harder and consume generator work.

If runtime uniqueness is used, include an engine/run prefix so independent generators cannot accidentally generate overlapping business keys under a weak custom scheme.

6. Committed fake fixtures versus ephemeral data

For the Academy, committed/generated synthetic data is sufficient. Real customer records are never a mandatory learning dependency.

7. Stable per-user identity versus iteration-driven CSV consumption

Because CSV rows update at each test iteration, a Thread Group loop can unintentionally rotate accounts. If each virtual user should keep one account while repeating a business action many times, allocate the account once per user and place the repeated action inside a nested Loop Controller. Chapter 12 will deepen this controller pattern.

8. Row-demand arithmetic must match the sharing domain

For one-time rows:

All threads shared cursor:
rows >= sum(iterations across all threads/groups sharing that cursor)

Current thread cursor:
rows in each thread's file >= that thread's outer iterations

Current thread group:
rows per group cursor >= iterations consumed by that group

Distributed:
global rows >= sum(rows consumed by every engine)
and shard sets must be disjoint

Include warm-up, retries only if explicitly modeled, setup calls that consume data, and repeated CI runs in capacity planning.

9. Relative paths versus absolute paths

Use repository/test-plan-relative paths for portability. Absolute paths can work on one workstation but fail on CI/remote engines. In distributed mode, provision the same relative path on every server host but place the correct engine-specific shard there.

10. Deterministic shard mapping versus filesystem ordering

Do not infer engine shard by “sort/list all CSVs and take index N” unless the ordering contract is explicitly guaranteed and tested. Directory enumeration can differ across OS/filesystems/tool versions.

Prefer an explicit manifest:

engine-a -> shards/engine-a/data/users.csv -> rows 1..6 -> sha256 ...
engine-b -> shards/engine-b/data/users.csv -> rows 1..6 -> sha256 ...

11. Privacy and credential boundaries

CSV is plain text. A password/API token stored there is readable by anyone with filesystem/artifact access and may later appear in requests/debug output. If credentials are unavoidable in a real authorized environment, use the platform's secret mechanism and minimize persistence; do not commit them.

Use synthetic emails such as acct-001@example.invalid, synthetic tokens, and fake IDs in training/repository fixtures.

12. Data strategy affects performance validity

Colliding users may trigger target locks, deduplication, cache locality, rate limits, or error branches. Recycled one-time IDs may artificially increase 4xx/409 rates. Runtime generation may consume injector CPU. Missing remote shards may stop threads. None of those should be misreported as server capacity behavior without attribution.

For every meaningful run, preserve the raw JTL together with its matching jmeter.log, the exact CSV/shard hash, and the non-secret run manifest. JTL shows achieved samples and failures; jmeter.log preserves engine-side file, EOF, and runtime diagnostics needed to distinguish data exhaustion from target failure.

13. Keep data allocation separate from surrounding layers

14. Decision table

Knowledge check

Official references and version notes

• Component Reference — CSV Data Set Config — row timing, headers, quoting, relative paths, EOF behavior, sharing modes, and per-thread file example.
• Remote (Distributed) Testing — remote engines execute the plan and have their own local runtime/filesystem state.
• Getting Started — GUI authoring/debugging and CLI execution conventions.
• Best Practices — generator validity, lean listeners, and pre-generated data guidance.
• Apache JMeter downloads — current production release and Java requirement.