GlossaryIdentifier

Identifier

An identifier is a unique label assigned to a resource, such as a test, test run, or workflow, so systems and people can track and reference it without ambiguity.

Table of Contents

Table of Contents

What Is an Identifier?

An identifier is a unique label assigned to a resource so it can be tracked and referenced without ambiguity. In testing, resources include tests, test runs, workflows, and artifacts.

Identifiers are how systems connect related data. A single run ID can tie together logs, metrics, screenshots, and reports from one execution.

Common Types of Identifiers

  • System-generated IDs: unique values created by the platform, often UUIDs
  • Human-readable names: short labels people use in commands and dashboards
  • Execution IDs: one value per test run for logs and results
  • Labels and tags: key-value pairs that group related resources
  • Kubernetes UIDs: cluster-assigned IDs for pods, jobs, and other objects
  • Commit SHAs: Git hashes that tie a run to the exact code version tested

Names vs. System-Generated IDs

Most platforms use both. Each one solves a different problem.

Aspect Human-Readable Name System-Generated ID
Example checkout-api-smoke A long random string
Best for People and CLI commands Automation and APIs
Uniqueness Unique within a scope Unique everywhere
Changes Can be renamed Stays fixed for life

Why Identifiers Matter for Engineering Teams

Without stable identifiers, test history falls apart. Teams cannot tell which log belongs to which run.

  • Traceability: every output links back to one execution.
  • Faster debugging: engineers jump straight to the failing run.
  • Reliable automation: scripts and APIs reference resources that never change ID.
  • Auditability: compliance reviews can follow a release to its exact test runs.
  • Trend analysis: history stays accurate even when tests are renamed.

Real-World Example

A B2B SaaS team is debugging a flaky checkout test that fails about once a week.

  1. Find the run: the failure alert includes the execution ID.
  2. Pull the evidence: the team filters logs, metrics, and artifacts by that ID.
  3. Compare: they line it up with passing runs from the same commit SHA.

The difference points to a slow dependency. Without the ID, they would have been guessing.

How Identifiers Relate to Testkube

Testkube assigns a unique identifier to every test, test run, and workflow at creation. That identifier stays constant for the resource lifecycle.

Every log entry, metric, and artifact links to its execution identifier. Teams can search and filter by identifier in the dashboard, API, and CLI.

Best Practices for Identifiers

  • Never reuse IDs: each resource and run needs its own value.
  • Use names for people, IDs for machines: automation should rely on fixed IDs.
  • Add labels for context: tag runs with branch, environment, or team.
  • Include IDs in alerts: notifications should link directly to the run.
  • Record the commit SHA: connect each run to the code it tested.

Frequently Asked Questions (FAQs)

Are identifiers the same as names?

No. A name is a readable label that can change. An identifier is a unique value that stays fixed for the resource lifecycle.

How does Testkube generate identifiers?

Testkube creates a unique identifier for each test, test run, and workflow when the resource is created.

Can I find a test by its identifier in Testkube?

Yes. You can search and filter by identifier in the Testkube dashboard, API, and CLI.

Do identifiers ever change?

No. An identifier stays the same for the life of the resource, so references and history stay accurate.

Why do test runs need their own identifiers?

Each run produces its own logs, metrics, and artifacts. A run identifier ties those outputs to the exact execution.

Related Terms and Concepts

No items found.