Testing Gatsby con Cypress usando Gitlab CI

Gatsby
Testing

En esta publicación de blog, veremos cómo podemos probar automáticamente un sitio de Gatsby de un extremo a otro (e2e), usando Cypress en Gitlab CI.
 

Introducción

Gatsby

Gatsby es un generador de sitios estáticos (SSG) basado en React. Nos permite crear sitios web ultrarrápidos. En este ejemplo, utilizaremos una plantilla de inicio de blog simple disponible y agregaremos una prueba de Cypress.               

Cypress

Cypress nos permite probar una aplicación web, cómo un usuario real usaría la aplicación. Cypress se utilizará para probar nuestra aplicación Gatsby, aunque si se trata de un sitio, puede probarlo con Cypress.

Gitlab CI

Gitlab CI es una canalización de integración continua que nos permitirá ejecutar nuestras pruebas automáticamente, como cuando fusionamos código en la rama maestra.

 

Empezamos

Gatsby

Cree un nuevo sitio de Gatsby, utilizando este iniciador de Gatsby predeterminado:

gatsby new gatsby-starter-blog https://github.com/gatsbyjs/gatsby-starter-blog

cd gatsby-starter-blog

Agregue lo siguiente a su gatsby-config.js.

module.exports = {
  plugins: [
    {
      resolve: `gatsby-plugin-typescript`,
      options: {
        isTSX: true, // defaults to false
        jsxPragma: `jsx`, // defaults to "React"
        allExtensions: true, // defaults to false
      },
    },
  ],
}

Luego cree un nuevo archivo tsconfig.json (en la raíz del proyecto, donde gatsby-config.js está).

 

Cypress

Ahora para finalmente agregar Cypress a nuestra aplicación para que podamos probarlo. Primero, instale las dependencias.

yarn add -D cypress cypress-axe axe-core start-server-and-test
# Add types
yarn add -D @types/cypress-axe

A continuación, creemos una cypress.json carpeta en la raíz del proyecto.

{
  "baseUrl": "http://localhost:8000/",
  "integrationFolder": "cypress/e2e"
}

A continuación, agreguemos algunos "scripts" nuevos al package.json.

"scripts": {
    "cy:open": "cypress open",
    "cy:run": "cypress run",
    "build": "gatsby build",
    "develop": "gatsby develop",
    "format": "prettier --write \"**/*.{js,jsx,ts,tsx,json,md}\"",
    "start": "npm run develop",
    "serve": "gatsby serve",
    "clean": "gatsby clean",
    "test": "echo \"Write tests! -> https://gatsby.dev/unit-testing\" && exit 1",
    "test:e2e": "start-server-and-test 'yarn develop' http://localhost:8000 'yarn cy:open'",
    "test:e2e:ci": "start-server-and-test 'yarn develop' http://localhost:8000 'yarn cy:run'"
}

Estos scripts nos permiten iniciar Cypress, cy:open abre una GUI para visualizar nuestras pruebas mientras cy:run que lo hace todo en la terminal (el navegador se ejecuta en modo headless). Donde ejecutaremos test:e2e:ci nuestra canalización de CI, aquí usamos el start-server-and-test comando para iniciar nuestro servidor Gatsby usando yarn develop. Luego corremos cy:run para comenzar nuestras pruebas.

 

Estructura

Crea una nueva carpeta llamada cypress que se verá así.

.
├── e2e
│   └── accessibility.test.ts
├── fixtures
│   └── graphql.json
├── plugins
│   └── index.js
├── support
│   ├── commands.js
│   ├── index.d.ts
│   └── index.js
└── tsconfig.json

mkdir -p cypress/support

Crea el fichero en cypress/support/commands.js

Cypress.Commands.add(`assertRoute`, (route) => {
  cy.url().should(`equal`, `${window.location.origin}${route}`);
});

Agregue algunos tipos personalizados para Cypress index.d.ts si está utilizando TypeScript.
Ahora crea el index.js archivo, que debería verse así
Ahora creemos una carpeta de complementos mkdir -p cypress/plugins
Ahora, finalmente, creemos nuestra carpeta de pruebas mkdir -p cypress/e2e

cypress-axe

En esta publicación de blog, no cypress-axe repasaremos ninguna prueba de Cypress complicada que simplemente usaremos para probar la accesibilidad de nuestro (a11y) de nuestro sitio web.

Tenga en cuenta los /// comentarios en la parte superior utilizados para agregar tipos de Cypress. La prueba anterior irá a nuestra página de inicio y probará si tiene alguna infracción y, de ser así, no pasará la prueba.

Ahora podemos ejecutar nuestras pruebas localmente ejecutando este comando:

yarn run test:e2e

 

Gitlab CI

Ahora, ¿cómo podemos automatizar esto, para que las pruebas se ejecuten, digamos, cada vez que hagamos cambios en la rama maestra para asegurarnos de que no hemos roto ninguno? Cree un trabajo nuevo .gitlab-ci.yml o agregue el siguiente trabajo a un archivo CI existente.

image: node:12.14.1

variables:
  CYPRESS_CACHE_FOLDER: "$CI_PROJECT_DIR/cache/Cypress"

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - cache/Cypress
    - node_modules

stages:
  - test

before_script:
  - yarn install

tests:
  image: cypress/browsers:node12.14.1-chrome83-ff77
  stage: test
  script:
    - yarn test:e2e:ci

No entraré en detalles sobre lo que constituye un archivo CI de Gitlab. En la parte superior del archivo, almacenaremos el node_modules archivo en caché para poder compartirlo entre el trabajo y el caché de Cypress. El trabajo en sí es muy simple, utiliza una cypress/browsers:node12.14.1-chrome83-ff77 imagen de Docker que proporciona un navegador Chrome sin cabeza que Cypress puede aprovechar para ejecutar las pruebas. Como no tendremos acceso a una GUI en el corredor de Gitlab CI. El tests trabajo es muy simple, se ejecuta yarn test:e2e:ci para ejecutar nuestras pruebas de Cypress.

Eso es todo, es bastante simple agregar pruebas de Cypress que se ejecutan en nuestra tubería de CI.