Fuentes de Datos

Las fuentes de datos (Data Sources) en Testform permiten que los recursos y configuraciones hagan referencia a información de solo lectura externa o previamente gestionada, de forma idéntica a cómo funciona el bloque data en Terraform.

Con data:, puedes:

1. Referenciar recursos existentes (address): Consultar IDs remotos, títulos, etiquetas o campos personalizados de otros casos de prueba o suites sin gestionarlos directamente.
2. Cargar datasets y fixtures externos (file): Inyectar datos dinámicos desde archivos JSON o YAML (fixtures/users.json, data/pagos.yml) hacia tus pasos Gherkin, variables locales y outputs.

---

1. Declaración Scopeless y Ubicación de Archivos

Al igual que las variables y outputs, las fuentes de datos pueden definirse en:

• main.yml (Manifiesto Base)
• data.yml o data.yaml (Archivo dedicado a datasets)
• Archivos de dominio como auth.yml, checkout.yml, etc.

Por defecto, Testform adopta un diseño scopeless (sin forzar anidación en testcase:, testrun:, etc.) porque la dirección de un recurso (address) ya identifica unívocamente el tipo y la ruta del archivo.

# data.yml o main.yml
data:
  # Declaración compacta directa (auto-detección sin líneas gastadas)
  usuarios: "fixtures/users.json"
  login_core: "auth/login.case.feature.@tc-1"
  smoke_suite: "suites/smoke.run.feature.@tr-1"

  # O mediante bloques tipados explícitos:
  local_file:
    catalogo: "fixtures/catalogo.yml"
  testcase:
    login_admin: "auth/admin.case.feature.@tc-admin"

[!NOTE] Gracias a la detección de extensiones (.json, .yml, .yaml, .csv) y patrones de recursos (.case.feature, .run.feature, @tags), no requieres gastar líneas adicionales en propiedades intermedias como filename: o address: a menos que desees personalizar opciones avanzadas.

---

2. Modos de Data Sources

A. Modo Fixture / Archivo (file)

Carga un archivo JSON o YAML estructurado para inyectar credenciales, parámetros de prueba o matrices de datos.

fixtures/users.json:

{
  "standard_user": {
    "username": "standard_user",
    "password": "secret_sauce",
    "role": "tester"
  },
  "locked_out_user": {
    "username": "locked_out_user",
    "password": "secret_sauce"
  }
}

main.yml:

data:
  usuarios_saucedemo: "fixtures/users.json"

Acceso:

• ${data.usuarios_saucedemo.standard_user.username} -> "standard_user"
• ${data.usuarios_saucedemo.standard_user.password} -> "secret_sauce"

---

B. Modo Referencia a Recurso (address)

Consulta atributos de un recurso registrado en el estado de Testform (o analizado estáticamente en el repositorio).

Atributos expuestos automáticamente:

Atributo	Descripción	Ejemplo
.id / .remoteId	ID remoto asignado por el provider	local:10 o 1024
.identity	Dirección canónica única en el estado	auth/login.case.feature.@tc-1
.tag	Tag específico del escenario	@tc-1
.uri	Ruta al archivo .feature	auth/login.case.feature
.title	Título del escenario o suite	Inicio de sesión exitoso
.labels	Lista de etiquetas del recurso	["auth", "smoke"]
.status	Estado de ejecución (PASSED, FAILED)	PASSED
.custom_fields.*	Campos personalizados del provider	${data.login.custom_fields.priority}

---

3. Uso en Pasos Gherkin y Plantillas

Puedes interpolar fuentes de datos en cualquier archivo .feature, en pasos de prueba, nombres de escenarios o etiquetas:

@auth @data-driven
Feature: Autenticación de Usuarios

  @tc-login-standard
  Scenario: Login con usuario estándar desde fixture
    Given el usuario navega a la página de login
    When ingresa el usuario "${data.usuarios_saucedemo.standard_user.username}"
    And ingresa la contraseña "${data.usuarios_saucedemo.standard_user.password}"
    And presiona el botón de login
    Then debería ver la página principal de productos

---

4. Uso en locals: y output:

Puedes combinar fuentes de datos con variables locales y exponerlas en los outputs de tu ejecución:

locals:
  usuario_activo: "${data.usuarios_saucedemo.standard_user.username}"
  login_id: "${data.login_core.remoteId}"

output:
  active_user:
    description: "Usuario utilizado en las pruebas"
    value: "${local.usuario_activo}"

  referenced_case_id:
    description: "ID del caso de prueba referenciado"
    value: "${data.login_core.id}"

---

5. Resumen de Ventajas

1. Desacoplamiento total: Los datos de prueba ya no se hardcodean en los archivos .feature.
2. Reutilización entre suites: Múltiples suites pueden compartir los mismos fixtures y consultar el estado de casos de prueba comunes.
3. Fidelidad Terraform: Comportamiento semántico idéntico a las fuentes de datos de Terraform (data "..." "...").