Accessibility tests #13

Vinicius-Ferraz · 2024-10-16T20:04:57Z

Creation of accessibility tests and a relatory disposal of the failures

wlsf82

Parabéns pela resolução dos exercícios @Vinicius-Ferraz! 👏🏻

Deixei comentários ao longo do seu código, os quais creio que lhe ajudarão a melhorar o design dos testes.

Lembre-se de só aplicar as mudanças sugeridas depois do próximo encontro da Test Design Masterclass (depois do encontro de 19/10/2024).

wlsf82 · 2024-10-17T15:50:15Z

cypress.config.js

+  e2e: {
+    setupNodeEvents(on, config) {
+      // implement node event listeners here
+      on('task', {


Qual a moral dessa task? Poderia explicar, por favor?

wlsf82 · 2024-10-17T15:51:42Z

cypress.env.json

@@ -0,0 +1 @@
+{"baseurl": "http://localhost:3000"}


O arquivo cypress.env.json, não deveria ser versionado.

Ele deveria estar listado no arquivo .gitignore.

A baseUrl deveria ser definida dentro da propriedade e2e do arquivo cypress.config.js.

No arquivo cypress.env.json define-se dados sensíveis, os quais não são versionados, ou seja, não são enviados ao GitHub.

Opa, isso foi um descuido!
Eu terminei o exercício em outro pc, aacabei passando isso batido. Vou corrigir!

wlsf82 · 2024-10-17T15:53:27Z

cypress/e2e/a11y.cy.js

+
+describe('EngageSphere', () => {
+    beforeEach(() => {
+


Qual o motivo dessa linha em branco?

Ela só deixa o arquivo uma linha maior, sem nenhum ganho.

Veja uma explicação detalhada abaixo.

Excesso de linhas em branco

É comum alunos/as excederem o número de linhas em branco na base de código de testes em geral.

Exemplo:

describe('EngageSphere', () => { beforeEach(() => { cy.visit('/') }) it('shows the default greeting (i.e., Hi, there...)', () => { // Test implementation here }) it('shows the customized greeting (i.e., Hi, Joe...)', () => { // Test implementation here }) // Outros casos de teste aqui… })

Por que tal prática fere um bom design de testes?

Em vez de ajudar na legibilidade do código, tal prática piora a mesma, visto que torna os arquivos maiores do que o necessário.

Sugestão com um melhor design

Não deixe linhas em branco no início do arquivo, nem mais de uma linha entre diferentes “coisas” (ex.: blocos it, beforeEach, context, etc.). Uma linha em branco já é o suficiente para deixar a suíte de testes legível.

Veja um exemplo.

describe('EngageSphere', () => { beforeEach(() => { cy.visit('/') }) it('shows the default greeting (i.e., Hi, there...)', () => { // Test implementation here }) it('shows the customized greeting (i.e., Hi, Joe...)', () => { // Test implementation here }) // Outros casos de teste aqui... })

Percebe a simplicidade?

wlsf82 · 2024-10-17T15:55:16Z

cypress/e2e/a11y.cy.js

+describe('EngageSphere', () => {
+    beforeEach(() => {
+
+      cy.visit('http://localhost:3000')


Evite deixar a URL da aplicação hardcoded nos testes.

Veja uma explicação detalhada abaixo.

URL da aplicação hardcoded nos testes

É comum alunos/as escreverem scripts de testes com a URL da aplicação codificada diretamente no(s) arquivo(s) de testes (cypress/e2e/gui/*.cy.js), conforme exemplo abaixo:

cy.visit('http://localhost:3000')

Por que tal prática fere um bom design de testes?

Tal prática impossibilita a execução dos mesmos testes contra diferentes ambientes (ex.: local, homologação e produção) sem a necessidade da alteração da URL no arquivo do testes, ou na duplicação de testes para diferentes ambientes.

Sugestão com um melhor design

Em vez de codificar a URL da aplicação direto no arquivo de testes, é recomendado definir a baseUrl no arquivo de configurações (cypress.config.js).

Por exemplo:

// cypress.config.js const { defineConfig } = require('cypress') module.exports = defineConfig({ e2e: { baseUrl: 'http://localhost:3000', }, })

Dessa forma, é possível passar somente a URL relativa no arquivo de testes (ex.: cy.visit('/'))

Isso permite a mudança da URL através de argumentos de linha de comando, possibilitando a fácil execução dos mesmos testes contra diferentes ambientes, sem a necessidade de modificação nos testes propriamente ditos.

Exemplo: npx cypress run --config baseUrl='https://engage-sphere.vercel.app'

O exemplo acima sobrescreve a baseUrl padrão pela URL de produção, para execução dos mesmos testes contra o ambiente produtivo.

Obs.: Para que tal abordagem seja efetiva, os testes devem ser implementados de forma que possam ser executados contra diferentes ambientes, ou seja, deve-se pensar em variáveis de ambiente para credenciais de acesso de diferentes ambientes, massa de dados, etc.

wlsf82 · 2024-10-17T15:55:47Z

cypress/e2e/a11y.cy.js

+    beforeEach(() => {
+
+      cy.visit('http://localhost:3000')
+      cy.setCookie('cookieConsent','accepted')


wlsf82 · 2024-10-17T15:59:31Z

cypress/e2e/a11y.cy.js

+
+    it('It finds on a11y issues with the messenger\'s bubble button in dark mode', () => {
+      cy.get('[aria-label*="theme"]').click()
+      cy.get('[aria-label*="messenger"]').click().pageAccessibility()


Mesma coisa aqui.

wlsf82 · 2024-10-17T16:00:25Z

cypress/fixtures/axe-rules.json

@@ -0,0 +1,827 @@
+[


Você não deveria precisar disso, visto que está usando uma lib (cypress-axe) para fazer isso.

A moral de usar uma lib é não precisar "re-inventar a roda".

Se você rodar os testes, essas "regras" são só pra gerar um report mais amigável.
Eu deixei 2 exemplos de "violações" onde você consegue ver o report de forma mais acessível. Daí usando a função de callback, eu me "apoio" nesse json pra ela poder pegar os dados e realizar a tradução.

Mas confesso que foi um artíficio fruto de pesquisas, não sei se teria uma outra forma mais adequada como retirar e buscar isso direto dentro da lib.

Um exemplo de como ficar o report:

Se este é o caso, recomendo usar o seguinte módulo do npm: https://www.npmjs.com/package/wick-a11y

Dessa forma você não precisa implementar isso "na mão".

FYI @Vinicius-Ferraz. ☝🏻

wlsf82 · 2024-10-17T16:00:51Z

cypress/support/acessibility-commands.js

@@ -0,0 +1,87 @@
+import rules from "../fixtures/axe-rules.json";


Você não deveria precisar disso, visto que está usando uma lib (cypress-axe) para fazer isso.

A moral de usar uma lib é não precisar "re-inventar a roda".

wlsf82 · 2024-10-17T16:01:42Z

package.json

@@ -6,7 +6,8 @@
    "install:frontend": "cd frontend && npm install",
    "install:backend": "cd backend && npm install",
    "start:frontend": "cd frontend && npm start",
-    "start:server": "cd backend && npm start"
+    "start:server": "cd backend && npm start",
+    "cypress:open": "cypress open"


Que tal criar um script também para a execução dos testes em modo headless?

Algo assim:

"test": "cypress run"

wlsf82 · 2024-10-17T16:03:53Z

package.json

@@ -30,5 +34,8 @@
      "last 1 firefox version",
      "last 1 safari version"
    ]
+  },
+  "dependencies": {
+    "cypress": "^13.15.0"


O Cypress deveria ser instalado nas devDependencies, não em dependencies.

Veja uma explicação detalhada abaixo.

Instalação de libs (ou packages) como dependencies em vez de devDependencies

É comum alunos/as instalarem packages do npm que servem para suportar o desenvolvimento de aplicações como dependencies em vez de devDependencies.

Por que tal prática fere um bom design de testes?

Tal prática prejudica o desempenho do projeto, visto que mais pacotes externos exigem mais tempo para serem baixados da internet e em esteiras de entrega contínua, é possível configurar que somente as dependencies sejam instaladas no momento da implantação de uma nova versão em um ambiente produtivo, por exemplo, sem perda de tempo instalando devDependencies.

Sugestão com um melhor design

Basta entender o pra que serve cada pacote e instalar os pacotes certos do jeito certo.

Aqui vai uma breve explicação:

No contexto de módulos npm, a principal diferença entre dependencies e devDependencies está no momento em que os pacotes são necessários:

dependencies: São os pacotes essenciais que o projeto precisa para funcionar em produção. Esses módulos são instalados quando o projeto é executado em ambientes finais, como servidores de produção ou em builds de lançamento. São usados diretamente pelo código do projeto durante a execução (ex.: React).

devDependencies: São pacotes usados apenas durante o desenvolvimento e testes do projeto. Incluem ferramentas como linters, frameworks de testes e geradores de documentação. Esses módulos não são necessários em produção e, portanto, não são instalados quando o projeto é implementado nesse ambiente, exceto se forem explicitamente requisitados.

Em resumo, dependencies são para a execução do projeto, enquanto devDependencies são para o suporte ao desenvolvimento do mesmo.

Accessibility tests

6495cc0

wlsf82 requested changes Oct 17, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Accessibility tests #13

Accessibility tests #13

Vinicius-Ferraz commented Oct 16, 2024

wlsf82 left a comment

wlsf82 Oct 17, 2024

wlsf82 Oct 17, 2024

Vinicius-Ferraz Oct 17, 2024

wlsf82 Oct 17, 2024

wlsf82 Oct 17, 2024

wlsf82 Oct 17, 2024

wlsf82 Oct 17, 2024

wlsf82 Oct 17, 2024

Vinicius-Ferraz Oct 17, 2024

Vinicius-Ferraz Oct 18, 2024

wlsf82 Oct 31, 2024

wlsf82 Oct 31, 2024

wlsf82 Oct 31, 2024

wlsf82 Oct 17, 2024

wlsf82 Oct 17, 2024

wlsf82 Oct 17, 2024

		@@ -0,0 +1,87 @@
		import rules from "../fixtures/axe-rules.json";

Accessibility tests #13

Are you sure you want to change the base?

Accessibility tests #13

Conversation

Vinicius-Ferraz commented Oct 16, 2024

wlsf82 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Excesso de linhas em branco

Por que tal prática fere um bom design de testes?

Sugestão com um melhor design

Choose a reason for hiding this comment

URL da aplicação hardcoded nos testes

Por que tal prática fere um bom design de testes?

Sugestão com um melhor design

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Instalação de libs (ou packages) como dependencies em vez de devDependencies

Por que tal prática fere um bom design de testes?

Sugestão com um melhor design

Instalação de libs (ou packages) como `dependencies` em vez de `devDependencies`