Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Define LibreSign Behat taxonomy and reusable context conventions

Abierto Apto para principiantes
  • ¿Algo no está bien?
#8,971 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@maia-andre ya está trabajando en esto.

Desde el 25/10/2026.

  • #9235 de @maia-andre — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
78/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
php
Área
documentation, testing-qa

Línea de trabajo

Crea o actualiza tests/integration/README.md con los cuatro tags aprobados, exclusiones explícitas, los límites de responsabilidad de Context y las convenciones de diseño de steps de Behat 4. Revisa escenarios existentes representativos del comportamiento de API/OCS, OCC, page/HTML y servicios auxiliares, y documenta después las clasificaciones que no usan tags adicionales.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

backend enhancement php

Part of #8969.

Context

The LibreSign Behat suite spans API/OCS calls, OCC interactions, page/HTML behavior and tests that require auxiliary services such as Mailpit, TSA or fixture servers.

Behat 4 supports Cucumber tag expressions. The suite needs a small semantic taxonomy for focused local execution and CI selection, but shard assignment must remain automatic and must not be encoded in tags.

This issue also defines where generic Nextcloud test primitives belong versus LibreSign domain steps.

Goal

Document and adopt one clear convention for Behat tags, reusable Context ownership and step design before the suite-wide application work in #8972.

Initial tag taxonomy

Use only the following execution/interface tags in the initial migration:

@api

Apply when the scenario's behavior under test is exercised primarily through HTTP API/OCS endpoints.

Do not add @api merely because setup internally uses an HTTP request.

@occ

Apply when invoking or validating an OCC command is material to the scenario behavior.

Do not add @occ merely because incidental environment setup uses OCC.

@web

Apply when the scenario validates a web/page route, HTML response or other browser-facing web behavior rather than an API/OCS contract.

This tag does not imply that Playwright/browser automation is used.

@external

Apply when the scenario requires an auxiliary service/process outside the Nextcloud application process in order to exercise the behavior, such as Mailpit, the local TSA service or a fixture HTTP service.

@external means external to the Nextcloud application process; it does not mean public Internet access.

Tags intentionally not introduced yet

Do not introduce these during this epic unless a later concrete requirement creates a separate issue:

  • manual shard/worker tags such as @shard1 or @worker2;
  • domain tags such as @signing, @certificate, @policy or @notification; the current feature-directory/name structure already carries this organization;
  • @slow; runtime classification should be introduced only after measured timings establish a concrete CI use case and an objective threshold;
  • generic @network, because most integration scenarios already involve networking and the tag would not define a useful filter.

A scenario may carry more than one of the four approved tags when the meanings independently apply.

Context/step ownership

Use this boundary:

  • libresign/nextcloud-behat: generic Nextcloud/API/OCS/OCC primitives that are reusable by another Nextcloud app;
  • LibreSign FeatureContext and LibreSign integration code: signing, certificate, participant, envelope, policy and other LibreSign-specific behavior.

Before adding a LibreSign step for generic Nextcloud behavior, check whether nextcloud-behat already provides the primitive or whether the primitive belongs there.

Do not move a step into nextcloud-behat merely to reduce code in LibreSign if its vocabulary or behavior is LibreSign-specific.

Step-design convention

New or refactored steps should:

  • describe observable behavior rather than internal implementation calls when practical;
  • keep Given/When/Then responsibility clear;
  • avoid combining unrelated actions and assertions;
  • use explicit parameter types compatible with Behat 4;
  • use DataTable or DocString when structured input is clearer than several positional parameters;
  • avoid passing hidden state between scenarios;
  • preserve useful existing step text when the contract is already clear.

Documentation location

Create or update a concise tests/integration/README.md with these code-adjacent conventions so a contributor editing a feature can find the rules without searching the epic.

Full developer execution instructions belong in the canonical LibreSign/documentation workflow handled by the final cleanup/documentation issue.

Verification

Before closing this issue, demonstrate the documented taxonomy against representative existing scenarios:

  • one API/OCS scenario;
  • one OCC scenario if present;
  • one page/HTML scenario;
  • one scenario requiring an auxiliary service.

This verification is about proving the definitions are unambiguous; the suite-wide tagging is #8972.

Done when

  • The four approved tags (@api, @occ, @web, @external) are documented with the definitions above.
  • Shard, domain, @slow and generic network tags are explicitly excluded from the initial migration.
  • Generic Nextcloud versus LibreSign domain step ownership is documented.
  • Behat 4 step-design conventions are documented.
  • tests/integration/README.md contains the code-adjacent conventions.
  • Representative existing scenarios can be classified without inventing another tag.
Lenguaje dominante
PHP
Estrellas
835
Forks
167
Merge medio
1 d 3 h
PR fusionados (30 d)
414

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de LibreSign/libresign

Todos los issues de LibreSign/libresign

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.