Lista de verificación de decisiones para formularios con Gherkin
Escribe escenarios Gherkin BDD en los que stakeholders y desarrolladores acuerden el comportamiento antes de programar, usando un formulario de perfil de arquitecto cloud como proyecto de ejemplo realista.
nota: Lo siguiente es un ejemplo; hay varias formas válidas de implementar el formulario. La clave es usar Gherkin para fijar el comportamiento esperado antes de escribir cualquier código de componente.
Mantén un nivel de detalle equilibrado en los escenarios: suficiente para especificar el comportamiento esperado sin dictar la implementación exacta.
Los escenarios deben ser legibles para stakeholders no técnicos y, al mismo tiempo, ofrecer una guía clara para los desarrolladores.
Los escenarios Gherkin son especificaciones ejecutables escritas en lenguaje claro (Given/When/Then). Cierran la brecha entre los requisitos de negocio y el código de prueba:
Stakeholders los leen como criterios de aceptación
Desarrolladores los implementan como pruebas automatizadas
QA los usa como plan de pruebas fuente de verdad
Todos acuerdan el comportamiento antes de escribir una sola línea de código de componente
Cada decisión a continuación se responde para el formulario de perfil de arquitecto cloud, seguida de los escenarios Gherkin que fijan el comportamiento esperado.
Decisión: Creación de perfil profesional para arquitectos cloud: captura identidad, experiencia, historial laboral, habilidades y cargas de portfolio para una plataforma de talento.
Por qué importa para Gherkin: El propósito determina qué campos son obligatorios, qué validación es crítica y cómo es el flujo posterior al envío.
Feature: Cloud Architect Profile Creation Background: Given the architect is logged in And they navigate to "/profile/create" Scenario: New architect sees empty profile form Then they should see a multi-step form with 6 steps And step 1 "Personal Info" should be active And a progress indicator should show "Step 1 of 6" Scenario: Completed profile is visible on the platform Given the architect has submitted a valid profile When a recruiter searches for "AWS Solutions Architect" Then the architect's profile should appear in results
Enfoque sugerido: Personaliza campos, validación y flujo posterior al envío para que coincidan exactamente con el caso de uso. Así el formulario resuelve la necesidad comercial real en lugar de construir campos genéricos que podrían requerir una remodelación pesada más adelante.
Decisión: Más de 20 campos repartidos en 6 pasos: text, email, tel, url, number, select, selección múltiple (grupo de checkbox), radio, date, textarea y carga de archivos.
Feature: Field Types and Input Behavior Scenario: Personal Info step has correct field types Given the architect is on step 1 "Personal Info" Then the "Full Name" field should be a text input And the "Email" field should be an email input And the "Phone" field should be a tel input And the "LinkedIn URL" field should be a url input Scenario: Experience step supports multi-select certifications Given the architect is on step 2 "Experience" When they check "AWS Solutions Architect Professional" And they check "Google Cloud Professional Architect" Then both certifications should be selected And the selected count should show "2 selected" Scenario: Job History supports repeatable entries Given the architect is on step 3 "Job History" When they click "Add Another Position" Then a new empty job entry group should appear And they should be able to add up to 10 positions Scenario: Skills step uses radio buttons for proficiency Given the architect is on step 4 "Skills" When they select "Expert" for AWS proficiency Then "Expert" should be selected And "Intermediate" and "Beginner" should not be selected
Enfoque sugerido: Usa react-hook-form (no controlado bajo el capó) para este formulario complejo con arrays de campos dinámicos. Prefiere useFieldArray para las entradas repetibles de Historial laboral.
Decisión: Varios pasos con 6 etapas. Más de 20 campos abrumarían a los usuarios en una sola página.
Feature: Multi-Step Navigation Scenario: Architect progresses through steps Given the architect is on step 1 "Personal Info" And they have filled in all required fields When they click "Next" Then step 2 "Experience" should be active And the progress indicator should show "Step 2 of 6" Scenario: Architect navigates back without losing data Given the architect is on step 3 "Job History" And they have entered "Acme Corp" as company name When they click "Back" And they click "Next" Then the company name field should still contain "Acme Corp" Scenario: Architect cannot skip ahead past invalid steps Given the architect is on step 1 "Personal Info" And the "Full Name" field is empty When they click step 3 in the progress indicator Then step 1 should remain active And a validation error should appear on the "Full Name" field Scenario: Architect can click completed steps to edit Given the architect has completed steps 1 through 4 And they are on step 5 "Uploads" When they click step 2 in the progress indicator Then step 2 "Experience" should be active And all previously entered data should be preserved Scenario: Progress indicator shows completion status Given the architect has completed steps 1 and 2 And they are on step 3 Then step 1 should show a checkmark icon And step 2 should show a checkmark icon And step 3 should show as "current" And steps 4 through 6 should show as "upcoming"
Enfoque sugerido: Usa varios pasos con un componente stepper y react-hook-form. Los formularios de varios pasos reducen la carga cognitiva y mejoran las tasas de finalización. Usa una sola instancia de useForm en todos los pasos para conservar el state.
Decisión: Validación basada en esquema con zod: campos obligatorios, validación de formato, reglas condicionales y validación entre campos.
Feature: Form Validation Scenario: Required fields show errors when empty Given the architect is on step 1 "Personal Info" And they have not filled in any fields When they click "Next" Then they should see "Full name is required" And they should see "Email is required" And the form should not advance to step 2 Scenario: Email format is validated Given the architect is on step 1 "Personal Info" When they type "not-an-email" in the "Email" field And they click "Next" Then they should see "Please enter a valid email address" Scenario: LinkedIn URL must be a valid LinkedIn profile Given the architect is on step 1 "Personal Info" When they type "https://twitter.com/someone" in the "LinkedIn URL" field And they click "Next" Then they should see "Please enter a valid LinkedIn profile URL" Scenario: Years of experience must be a positive number Given the architect is on step 2 "Experience" When they type "-3" in the "Years of Experience" field And they click "Next" Then they should see "Years of experience must be 0 or greater" Scenario: At least one cloud platform must be selected Given the architect is on step 4 "Skills" And no cloud platforms are checked When they click "Next" Then they should see "Select at least one cloud platform" Scenario: Job history dates must be logically valid Given the architect is on step 3 "Job History" When they set start date to "2025-06-01" And they set end date to "2024-01-01" And they click "Next" Then they should see "End date must be after start date" Scenario: Bio has a maximum character limit Given the architect is on step 2 "Experience" When they type 1001 characters in the "Bio" field Then they should see "Bio must be 1000 characters or fewer" And a character counter should show "1001 / 1000" Scenario: Real-time validation feedback on email Given the architect is on step 1 "Personal Info" When they type "alice@" in the "Email" field And they move focus to the next field Then they should see "Please enter a valid email address" When they go back and type "alice@example.com" Then the error message should disappear
Enfoque sugerido: Usa react-hook-form con zod para validación basada en esquema. Usa mode: "onBlur" para retroalimentación en tiempo real al perder el foco. Define un esquema zod por paso y un esquema combinado para el envío final.
Decisión: Server Action con useActionState: el formulario se envía al backend propio de la plataforma.
Feature: Form Submission Scenario: Successful profile submission Given the architect has completed all 6 steps with valid data When they click "Submit Profile" on the review step Then a loading spinner should appear on the submit button And the button should be disabled And after submission completes they should see "Profile created successfully!" And they should be redirected to "/profile/me" Scenario: Server returns validation errors Given the architect submits a profile with a duplicate email When the server responds with an error Then they should see "This email is already registered" And the form should navigate back to step 1 And the "Email" field should be highlighted Scenario: Network failure during submission Given the architect clicks "Submit Profile" And the network request fails Then they should see "Something went wrong. Please try again." And the submit button should be re-enabled And no data should be lost Scenario: Form data is sent as multipart/form-data Given the architect has uploaded a profile photo And they have filled all required fields When they submit the form Then the request should include the photo as a file upload And all text fields should be included in the payload
Enfoque sugerido: Usa server actions con useActionState para el backend propio. Maneja state pendiente, errores y mejora progresiva listos para usar. Usa FormData para cargas de archivos.
Decisión: shadcn/ui con Tailwind CSS v4, soporte de modo oscuro y transiciones animadas entre pasos.
Feature: UI/UX Requirements Scenario: Form renders with shadcn/ui components Given the architect opens the profile form Then all inputs should use shadcn/ui styled components And buttons should follow the design system And the form should have consistent spacing and typography Scenario: Dark mode support Given the system is in dark mode When the architect opens the profile form Then all form elements should render with dark theme colors And contrast ratios should meet WCAG AA standards Scenario: Step transitions are animated Given the architect is on step 1 When they click "Next" Then step 1 should slide out to the left And step 2 should slide in from the right And the transition should complete within 300ms Scenario: Form is visually organized with sections Given the architect is on step 2 "Experience" Then the certifications should be grouped in a card And the bio field should span the full width And help text should appear below complex fields
Enfoque sugerido: Usa shadcn/ui con Tailwind como la opción más accesible. shadcn/ui ofrece componentes totalmente personalizables y accesibles sin la sobrecarga de tamaño de bundle de bibliotecas de UI más grandes.
Decisión: Cumplimiento completo de WCAG 2.1 AA, navegación por teclado, soporte de lector de pantalla y diseño responsivo.
Feature: Accessibility Scenario: All fields have accessible labels Given the architect is on any form step Then every input should have an associated label element And every required field should have aria-required="true" Scenario: Keyboard navigation through form Given the architect is on step 1 When they press Tab Then focus should move to the first input field And they should be able to Tab through all fields in order And they should be able to submit using Enter Scenario: Screen reader announces validation errors Given the architect submits step 1 with empty required fields Then each error message should have role="alert" And the screen reader should announce the first error Scenario: Screen reader announces step changes Given the architect completes step 1 and moves to step 2 Then the screen reader should announce "Step 2 of 6: Experience" Scenario: Mobile responsive layout Given the architect is using a mobile device (viewport 375px) Then the form should stack fields vertically And the progress indicator should be compact And touch targets should be at least 44x44 pixels And the "Next" and "Back" buttons should be full-width
Enfoque sugerido: Usa HTML semántico, la accesibilidad integrada de react-hook-form y clases responsivas de Tailwind. Una accesibilidad adecuada desde el inicio evita correcciones costosas más adelante y asegura el cumplimiento de WCAG.
Decisión: Sí: foto de perfil (imagen única), diagramas de arquitectura (varias imágenes) y capturas del sitio (varias imágenes).
Feature: File Uploads Scenario: Architect uploads a profile photo Given the architect is on step 5 "Uploads" When they select a JPEG file under 5MB for "Profile Photo" Then a thumbnail preview should appear And the file name and size should be displayed Scenario: Profile photo validates file type Given the architect is on step 5 "Uploads" When they select a .exe file for "Profile Photo" Then they should see "Only JPEG, PNG, and WebP files are accepted" And the file should not be uploaded Scenario: Profile photo validates file size Given the architect is on step 5 "Uploads" When they select a 15MB image for "Profile Photo" Then they should see "File must be under 5MB" Scenario: Architect uploads multiple architecture diagrams Given the architect is on step 5 "Uploads" When they select 3 PNG files for "Architecture Diagrams" Then 3 thumbnail previews should appear And each should show a remove button And the upload count should show "3 files selected" Scenario: Architect removes an uploaded file Given the architect has uploaded 3 architecture diagrams When they click the remove button on the second diagram Then only 2 thumbnails should remain And the removed file should no longer be in the form data Scenario: Drag and drop file upload Given the architect is on step 5 "Uploads" When they drag a PNG file into the "Architecture Diagrams" drop zone Then the drop zone should highlight And when they drop the file a thumbnail preview should appear Scenario: Maximum file count is enforced Given the architect has uploaded 10 architecture diagrams When they try to add another file Then they should see "Maximum 10 files allowed" And the file input should be disabled
Enfoque sugerido: Usa input type="file" con react-hook-form y manéjalo con FormData para la API. Usa URL.createObjectURL para vistas previas en el cliente. Valida tipo y tamaño en el cliente antes de subir.
Decisión: TypeScript con react-hook-form y zod. El state del formulario vive en react-hook-form; no hace falta un gestor de state externo.
Feature: Type Safety and State Management Scenario: Form schema is defined with zod Given the developer creates the form schema Then each step should have its own zod schema And a combined schema should validate the full profile And TypeScript types should be inferred from the schema Scenario: Form state persists across steps Given the architect fills in step 1 and moves to step 3 When they navigate back to step 1 Then all fields should retain their values And no external state store should be required Scenario: Type errors are caught at compile time Given the developer passes incorrect field types Then the TypeScript compiler should report an error And the build should fail before runtime
Enfoque sugerido: TypeScript con react-hook-form y zod es el valor predeterminado muy recomendado. TypeScript detecta errores pronto y zod ofrece validación en runtime que coincide con los tipos en tiempo de compilación.
Decisión: Next.js 15 con App Router, TypeScript, react-hook-form, zod, shadcn/ui y Tailwind CSS v4.
Feature: Tech Stack Integration Scenario: Form works with App Router server actions Given the form component is a Client Component When the architect submits the form Then data should be processed by a Server Action And the page should not require a full reload Scenario: Form works without JavaScript (progressive enhancement) Given JavaScript is disabled in the browser When the architect submits the form Then the form should still submit via native HTML form submission And server-side validation should catch any errors Scenario: Form loads performantly Given the architect navigates to the profile form Then the initial bundle should not exceed 50KB gzipped for the form And code splitting should load step components lazily And the Largest Contentful Paint should be under 2.5 seconds
Enfoque sugerido: Usa Next.js 15 con App Router, TypeScript, react-hook-form, zod y shadcn/ui salvo que se indique lo contrario. Este stack moderno ofrece gran rendimiento, beneficios de SEO y una experiencia de desarrollo fluida.
Una vez tomadas las 10 decisiones, los archivos feature Gherkin completos se convierten en el contrato entre stakeholders y desarrolladores:
features/
profile-form/
01-purpose.feature # Qué hace el formulario
02-field-types.feature # Tipos de entrada y comportamiento
03-multi-step.feature # Navegación y progreso
04-validation.feature # Todas las reglas de validación
05-submission.feature # Flujo de envío y manejo de errores
06-ui-ux.feature # Estilos e interacciones
07-accessibility.feature # Cumplimiento WCAG
08-file-uploads.feature # Comportamiento de cargas
09-type-safety.feature # Garantías de TypeScript/esquema
10-tech-stack.feature # Rendimiento e integración
Tarjeta de referencia rápida - lista para copiar y pegar.
# Template: Gherkin scenario for any form decisionFeature: [Decision Area] -- [Form Name] Background: Given the user is logged in And they navigate to "[form URL]" Scenario: Happy path -- [what should happen] Given [precondition] When [user action] Then [expected outcome] Scenario: Validation -- [what should be rejected] Given [precondition] When [invalid action] Then [error message or blocked behavior] Scenario: Edge case -- [boundary condition] Given [precondition] When [edge case action] Then [expected handling]
Cuándo usarlo: Antes de escribir cualquier código de componente de formulario. Recorre la lista de verificación de 10 preguntas con los stakeholders, escribe los escenarios Gherkin, consigue la aprobación y luego implementa.
Escribir Gherkins después del código - anula el propósito. Escríbelos primero para que los stakeholders puedan revisar el comportamiento antes de que empiece la implementación.
Demasiado detalle de implementación en los escenarios - Gherkin debe describir qué ocurre, no cómo. Escribe Then debería ver "El email es obligatorio" y no Then el esquema zod debería devolver un objeto de error con path email.
Omitir el bloque Background - los pasos Given repetidos inflan cada escenario. Extrae las precondiciones comunes en Background.
Un único archivo feature gigante - divídelo por área de decisión (validación, navegación, cargas) para que distintos miembros del equipo puedan ser dueños de distintos archivos.
No mapear escenarios a código de prueba - los Gherkins sin automatización se convierten en documentación obsoleta. Usa Playwright + Cucumber o similar para mantenerlos ejecutables.