Back to Intro to Storybook
Chapters
  • Empezando
  • Componente Simple
  • Componente Compuesto
  • Datos
  • Pantallas
  • Desplegar
  • Testing
  • Complementos
  • Conclusion
  • Contribuir

Testear Componentes UI

Aprende las formas de hacer test a los componentes de la UI
Esta traducción de la comunidad aún no se ha actualizado a la última versión de Storybook. Ayúdanos a actualizarlo aplicando los cambios en la guía en español para esta traducción. Pull requests son bienvenidos.

Ningún tutorial de Storybook estaría completo sin hacer testing. Las pruebas son esenciales para crear interfaces de usuario de alta calidad. En los sistemas modulares, los ajustes minúsculos pueden dar lugar a regresiones importantes. Hasta ahora hemos encontrado tres tipos de pruebas:

  • Pruebas manuales confían en que los desarrolladores examinen manualmente un componente para verificar que esté correcto. Nos ayudan a comprobar la aparencia de un componente a medida que lo construimos.

  • Pruebas de accessibilidad verifican que los componentes sean accesible a todos usando el complemento a11y. Nos ayudan a recolectar información sobre cómo las personas con ciertos tipos de discapacidades usan nuestros componentes.

  • Pruebas de interacción con la función "play" verifican que el componente se comporta como se espera cuando se interactúa con él. Son excelentes para probar el comportamiento de un componente cuando se está usando.

"¿Pero se ve bien?"

Desafortunadamente, los métodos de testing mencionados no son suficientes para prevenir errores de interfaz de usuario. Las interfaces de usuario son difíciles de probar porque el diseño es subjetivo y matizado. Pruebas manuales necesitan mucho esfuerzo. Otros tipos de pruebas de interfaz de usuario, como las pruebas instantáneas (snapshot), provocan demasiado falsos positivos, y las pruebas unitarias a nivel de píxel son de poco valor. Una estrategia completa de pruebas de Storybook también incluye pruebas de regresión visual.

Pruebas de regresión visual para Storybook

Las pruebas de regresión visual están diseñadas para detectar cambios en la apariencia. Funcionan haciendo capturas de pantalla de todas las historias y comparándolas de commit a commit con los cambios superficiales. Esto es perfecto para verificar elementos gráficos como diseño, color, tamaño y contraste.

Storybook es una herramienta fantástica para las pruebas de regresión visual porque cada historia es esencialmente una especificación del test. ¡Cada vez que escribimos o actualizamos una historia recibimos una especificación gratis!

Existen varias herramientas para la prueba de regresión visual. Recomendamos Chromatic, un servicio de publicación gratuito creado por los mantenedores de Storybook que ejecuta pruebas visuales en un entorno de navegador en la nube. También nos permite publicar Storybook en línea, como vimos en el capítulo anterior.

Capturando un cambio en la interfaz de usuario

La prueba de regresión visual se basa en la comparación de imágenes del nuevo código de la interfaz de usuario renderizado con las imágenes de la línea base. Si se detecta un cambio en la interfaz de usuario, se notificará.

Vea cómo funciona ajustando el fondo del componente Task:

Empieza creando una nueva rama para este cambio:

Copy
git checkout -b change-task-background

Cambia src/components/Task.js al siguiente:

Copy
src/components/Task.js
export default function Task({ task: { id, title, state }, onArchiveTask, onPinTask }) {
  return (
    <div className={`list-item ${state}`}>
      <label
        htmlFor="checked"
        aria-label={`archiveTask-${id}`}
        className="checkbox"
      >
        <input
          type="checkbox"
          disabled={true}
          name="checked"
          id={`archiveTask-${id}`}
          checked={state === "TASK_ARCHIVED"}
        />
        <span
          className="checkbox-custom"
          onClick={() => onArchiveTask(id)}
        />
      </label>

      <label htmlFor="title" aria-label={title} className="title">
        <input
          type="text"
          value={title}
          readOnly={true}
          name="title"
          placeholder="Input title"
+         style={{ backgroundColor: 'red' }}
        />
      </label>

      {state !== "TASK_ARCHIVED" && (
        <button
          className="pin-button"
          onClick={() => onPinTask(id)}
          id={`pinTask-${id}`}
          aria-label={`pinTask-${id}`}
          key={`pinTask-${id}`}
        >
          <span className={`icon-star`} />
        </button>
      )}
    </div>
  );
}

Esto produce un nuevo color de fondo para el elemento.

task background change

Agrega el archivo:

Copy
git add .

Haz commit del archivo:

Copy
git commit -m "change task background to red"

Y haz push a los cambios al repositorio remoto:

Copy
git push -u origin change-task-background

Por último, abre tu repositorio de GitHub y abre un pull request para la rama change-task-background.

Creating a PR in GitHub for task

Agrega un texto descriptivo a tu pull request y haz clic en "Create pull request". Haga click en el PR check "🟡 UI Tests" en la parte inferior de la página.

Created a PR in GitHub for task

Le mostrará los cambios en la interfaz de usuario detectados por su commit.

Chromatic caught changes

Hay muchos cambios. La jerarquía de componentes donde Task es hijo de TaskList y Inbox significa que un pequeño cambio se convierte en grandes regresiones. Esta circunstancia es precisamente la razón por la que los desarrolladores necesitan pruebas de regresión visual además de otros métodos de prueba.

UI minor tweaks major regressions

Revisando cambios

Las pruebas de regresión visual aseguran que los componentes no cambien por accidente. Pero todavía depende de nosotros determinar si los cambios son intencionales o no.

Si un cambio es intencional, es necesario actualizar la línea base para que las pruebas futuras se comparen con la última versión de la historia. Si un cambio no es intencional, debe ser corregido.

Dado que las aplicaciones modernas se construyen a partir de componentes, es importante que probemos a nivel de componentes. Hacerlo nos ayuda a identificar la causa raíz de un cambio (el componente) en lugar de reaccionar a los síntomas de un cambio, las pantallas y los componentes compuestos.

Fusionando cambios

Cuando hayamos terminado de revisar, estaremos listos para fusionar o hacer "merge" de los cambios en la interfaz de usuario con confianza, sabiendo que las actualizaciones no introducirán errores accidentalmente. Si te gusta el nuevo fondo red entonces acepta los cambios, si no, vuelve al estado anterior.

Changes ready to be merged

Storybook te ayuda a construir componentes; las pruebas te ayudan a mantenerlos. Los cuatro tipos de pruebas de interfaz de usuario que se tratan en este tutorial son las pruebas visuales, de accessibilidad, de interacción y de regresión visual. Puedes automatizar los últimos tres añadiéndolos a un CI como acabamos de terminar de configurar, y nos ayuda a crear componentes sin preocuparnos por los errores ocultos. Todo el flujo de trabajo se ilustra a continuación.

Visual regression testing workflow

Is this free guide helping you? Tweet to give kudos and help other devs find it.
Next Chapter
Complementos
Aprende como integrar y utilizar el popular complemento Controls
✍️ Edit on GitHub – PRs welcome!
Join the community
6,536 developers and counting
WhyWhy StorybookComponent-driven UI
Open source software
Storybook

Maintained by
Chromatic
Special thanks to Netlify and CircleCI