Nombra los pasos por la pregunta que responden.

Un informe dice Paso 1 aprobado, Paso 2 aprobado y Paso 3 fallido. Mantiene el orden, pero explica poco. Otro dice Guardado correctamente cuando solo pulsó Guardar. Esa etiqueta explica demasiado: anuncia algo que el código nunca comprobó.

Esta guía usa la API de Playwright Test para una preferencia local inventada. No hay cuenta ni servidor. Queremos que los límites del informe coincidan con las preguntas que responde el código, sin convertir un nombre en prueba.

Da a cada paso una pregunta comprobable

test.step agrupa acciones en un paso nombrado. Usa el nombre para expresar intención y mantén dentro la aserción que responde. Leer la preferencia actual es más honesto que Preferencia guardada para siempre si solo se inspecciona una página.

await test.step('Read the current demo preference', async () => {
  await expect(page.getByRole('status')).toHaveText('Demo preference: off');
});
await test.step('Enable the local demo preference', async () => {
  await page.getByRole('button', { name: 'Enable demo preference' }).click();
  await expect(page.getByRole('status')).toHaveText('Demo preference: on');
});

El ejemplo requiere una muestra inventada e importar test y expect. Establece estados locales inicial y modificado, no recarga un registro del servidor ni demuestra persistencia. El título, los pasos y la captura deben conservar ese límite.

Separa preparación y evidencia

Abrir la muestra es preparación. Leer el estado inicial aporta evidencia. Pulsar es una acción y observar el estado nuevo aporta otra evidencia. Agruparlo todo como Completar flujo de preferencia oculta dónde cambió la pregunta.

Demasiados pasos diminutos también molestan. Crear un paso por cada localizador añade ruido sin explicar el producto. Agrupa por preguntas útiles, no por líneas ni por un número arbitrario de pasos.

Los pasos anidados pueden expresar jerarquía real, pero no entierres la aserción bajo nombres vagos. El revisor debe encontrarla sin abrir una cadena de Preparar, Procesar y Terminar.

Devuelve lo que realmente necesita el siguiente paso

La API documenta que test.step devuelve lo que retorna su función. Puede mantener un identificador controlado junto al paso que lo obtiene. Pasa solo lo necesario, no uses el límite como almacén global oculto.

El valor necesita validación. Un objeto existente no demuestra que sea el registro correcto. Explica el origen y las aserciones que establecen su significado. Usa datos autorizados y evita nombres privados en títulos públicos.

Verifica el informe con una ejecución local

El ejecutor ejecuta dos pasos y comprueba ambos estados. Una captura controlada muestra el resultado local. Los pasos aprueban, pero nada dicen de persistencia remota. El vídeo explica la estructura del informe; no graba un flujo de cliente.

Si falla un paso, el nombre debe ubicar la pregunta, no sustituir los detalles. Lee aserción y contexto. No todas las acciones de un paso aprobado fueron validadas individualmente. Un paso solo con clics puede aprobar sin comprobar el resultado prometido.

Revisa nombres y código juntos

La regla es breve: título expresa la pregunta, cuerpo contiene acción y aserción pertinentes, alcance honesto. Actualiza nombres cuando cambie la implementación. Una etiqueta antigua puede engañar aunque el código compruebe correctamente algo más limitado.

AnyTest describe exploración y pruebas para revisión. Pregunta si las etiquetas reflejan la evidencia del recorrido. No se afirma un formato de pasos concreto de AnyTest. Los nombres reducen esfuerzo de lectura; las aserciones siguen aportando la prueba.