Configure Providers

Los Providers en Testform son plugins modulares desacoplados que conectan la especificación declarativa de pruebas BDD con las plataformas de gestión de calidad y estado (GitHub Issues / Projects, GitLab, Jira o Ledger Local).

Al igual que en Terraform un provider gestiona la comunicación con la API de un proveedor de nube (AWS, Azure, GCP) para registrar el estado de la infraestructura, en Testform un provider gestiona la comunicación con el issue tracker o el almacenamiento de estado para crear, actualizar, cerrar y versionar casos de prueba y ejecuciones como código en Git.

Declaración en `main.yml`

Los providers se configuran en el archivo principal main.yml:

testform:
  required_version: ">= 1.0.0"
  backend:
    local:
      path: "./testform.state"

provider:
  github:
    owner: "mi-organizacion"
    repository: "mi-sistema-web"
    token_env: "GITHUB_TOKEN"
  jira:
    host: "mi-empresa.atlassian.net"
    project_key: "QA"
    email: "qa-team@empresa.com"

Providers Disponibles

Provider	Tipo de Almacenamiento	Uso Recomendado
`local`	Archivo local `testform.state`	Proyectos ágiles, pruebas locales y suites autónomas en Git sin dependencias externas.
`github`	GitHub Issues + GitHub Projects (GraphQL)	Equipos que centralizan sus especificaciones y ejecuciones en GitHub Enterprise / Cloud.
`gitlab`	GitLab Issues + Scoped Labels	Pipelines de GitLab CI/CD con trazabilidad en tableros de GitLab.
Custom Providers	Conectores propios registrados vía `registerResource()`	Integraciones a medida con herramientas propietarias de QA o TestRail/Xray.

Configuración Detallada de GitHub Provider (`provider: github`)

Cuando utilizas GitHub como proveedor de gestión de calidad, Testform interactúa con la API GraphQL de GitHub Projects (Projects V2) y la API REST de GitHub Issues. Para garantizar la sincronización bidireccional, el repositorio y la organización deben configurarse con las siguientes especificaciones:

1. Tablero GitHub Projects (Projects V2)

Debe existir un proyecto de GitHub Projects V2 (a nivel de organización o usuario) vinculado al repositorio.
El proyecto debe contener un campo de tipo selección única (Single-select) denominado exactamente Status.
El campo Status debe incluir obligatoriamente los siguientes valores de opción:
- Todo
- Done
- passed
- failed
- blocked
- skipped
- unexecuted

2. Etiquetas Requeridas (Labels)

Testform mapea los recursos declarativos (testcase, testrun, testplan, etc.) con etiquetas en las incidencias de GitHub. Las siguientes 5 etiquetas son obligatorias:

bug
testcase
testplan
testreport
testrun

3. Permisos de Autenticación (PAT)

El token de autenticación configurado (token_env o testform login) debe contar con los siguientes alcances:

Classic Personal Access Token (PAT):
- Scope repo (Acceso completo a repositorios privados/públicos).
- Scope project (Lectura y escritura en proyectos de GitHub).
Fine-Grained Personal Access Token:
- Repositorio: Permiso Issues en modo Read and write.
- Organización: Permiso Projects en modo Read and write.

Inicialización del Provider (`testform init`)

Antes de ejecutar un plan, testform init autentica y valida el provider configurado:

testform init

Durante el init:

Verifica las credenciales de acceso (tokens de entorno como GITHUB_TOKEN o GITLAB_TOKEN).
Configura el backend de estado y el archivo de bloqueo concurrente (.lock).
Comprueba el acceso al repositorio y a los tableros del proyecto.