Como mantemos a qualidade da sua academia utilizando testes de regressão visual

Recentemente, apresentámos a nossa nova interface da academia. Durante o desenvolvimento, começamos a usar algumas técnicas novas para nos ajudar a melhorar nosso fluxo de trabalho e manter um alto padrão de qualidade para nosso produto. Evitamos a ocorrência de erros trabalhando de forma orientada por componentes e testando com frequência alterações visuais não intencionais (regressões visuais).

Desenvolvimento orientado por componentes

Nos últimos anos, uma grande tendência no desenvolvimento da interface do utilizador tem sido o desenvolvimento orientado para os componentes (CDD). Os componentes são as peças mais pequenas de funcionalidade autónoma, que acrescentam valor por si só. O CDD ancora-se nisto ao criar um processo de construção que funciona de baixo para cima. Primeiro cria-se pequenos componentes que se ligam a componentes maiores, que juntos formam uma funcionalidade ou uma página. Pense nisso como se uma bicicleta fosse composta de partes menores. Começa por criar duas rodas, depois um quadro. Acrescenta um volante, alguns pedais e uma corrente. Agora começa a parecer-se com uma bicicleta. Foi assim que também desenvolvemos a interface da academia.

Temos inúmeras vantagens em trabalhar de uma forma orientada para os componentes:

• Os componentes são reutilizáveis. Se construir uma roda, pode usá-la para construir uma bicicleta maior ou menor, ou talvez até um triciclo.

• Componentes pequenos são fáceis de entender.

• Componentes são facilmente testáveis. Você pode testar se a roda funciona, você não tem que se preocupar com a bicicleta inteira ainda.

• Trabalhar com componentes muitas vezes acelera o nosso processo de desenvolvimento, fornecendo soluções plug and play.

• O desenvolvimento é focado. É fácil acompanhar as variações dos componentes.

• Existem ferramentas disponíveis para acompanhar facilmente todos os componentes disponíveis que foram criados por colegas.

Alguns exemplos de componentes que criámos são: um botão, uma janela pop-up, uma resposta de escolha múltipla e também uma página de início de sessão completa.

O Storybook permite-nos desenvolver componentes fora da nossa aplicação num ambiente isolado, sem nos preocuparmos com dependências ou quebras na aplicação.

A história da nossa interface no Storybook

Depois de criar muitos componentes que são a espinha dorsal de nossa interface, nós os organizamos no Storybook. Storybook é um explorador de componentes, ou biblioteca de componentes. É uma maneira eficiente de manter o controle de todos os nossos componentes. Cada componente tem sua própria história no Storybook, onde todas as variações possíveis de um componente podem ser vistas: 

Componente de botão no Storybook

Para um componente de botão, por exemplo, é possível ver um botão predefinido, um botão elevado, um botão não elevado e um botão desativado. Também é possível interagir com o componente para ver como isso altera o estado ou o comportamento do componente. Escreva algo no formulário de início de sessão, por exemplo, e os campos de entrada dir-lhe-ão se a entrada é válida:

Componente de formulário de login no Storybook

O Storybook permite-nos desenvolver componentes fora da nossa aplicação num ambiente isolado, sem nos preocuparmos com dependências ou quebras na aplicação.

Utilizamos o Storybook como uma ferramenta de design, uma vez que adoptámos uma estratégia de design baseada em histórias. Quando desenhamos, estamos a criar diretamente algo que é valioso. Em vez de criarmos transferências de Photoshop inúteis como costumávamos fazer antes. Quando adicionamos histórias de componentes ao Storybook, estamos automaticamente a contribuir para um guia de estilo vivo, ou uma biblioteca de interfaces de utilizador. Isso significa que um desenvolvedor pode facilmente escolher entre uma ampla gama de componentes pré-fabricados para adicionar a um recurso que está criando. Isso faz com que nossa interface seja consistente e relativamente barata de desenvolver:

Componente da página de login no Storybook

Utilizando add-ons, alargámos o Storybook, de modo a podermos testar a acessibilidade de cada componente. Garantimos que a interface se mantém acessível para utilizadores com determinadas restrições:

Verificação de acessibilidade no Storybook

Teste de regressão visual com Percy

Anteriormente, falámos de regressões visuais que são alterações visuais não intencionais. Para tomar conhecimento dessas alterações visuais, usamos uma ferramenta chamada Percy. Percy é uma ferramenta de teste de regressão visual que se preocupa apenas com a integridade visual.

Com o Storybook, posso construir e estilizar componentes isoladamente, e sempre tenho uma visão geral dos diferentes cenários que projetei. Com a ajuda do Percy, sei sempre o impacto das alterações que faço.
Anouk
Front-End Developer & UX Designer

Para cada componente que desenvolvemos na nossa biblioteca de componentes Storybook, é feita uma captura de ecrã. Quando alteramos um componente, é feita uma nova captura de ecrã e as duas são comparadas lado a lado. As diferenças são então marcadas a vermelho para mostrar claramente o que mudou:

Regressões tornadas visíveis em Percy

As diferenças entre a versão antiga e a nova estão marcadas em vermelho

O Percy está diretamente ligado ao nosso pipeline de integração contínua (o fluxo da ideia para a realidade), notificando-nos de regressões visuais antes de as alterações entrarem em funcionamento. Após uma revisão por um dos designers, as alterações são aceites ou recusadas. O Percy também permite uma discussão sobre uma determinada alteração:

Percy se integrou ao nosso pipeline, dizendo que algo precisa ser revisto

Tudo isto ajuda-nos a evitar que as alterações visuais indesejadas cheguem até si, os nossos utilizadores finais. Mas aconteceu um erro visual passar despercebido? Continue a ler para saber como lidamos com isso neste artigo