Aprenda como entender a estrutura de dados que sua aplicação espera para a criação de fixtures de testes

Se você prefere assistir à um vídeo em vez de ler um blog post, aqui vai uma versão  deste conteúdo no YouTube https://youtu.be/2RK3f0tGOIs.

Recentemente, fiz uma live no YouTube para explorar e testar a aplicação Memos.

Após a live, continuei brincando com a aplicação e percebi que requisições HTTP são feitas para buscar os dados listados em algumas caixas de diálogo, tais como as caixas de Recursos (Resources) e Memos arquivados (Archived Memos).

Veja as screenshots abaixo para entender de quais caixas de diálogo estou falando.

Menu suspenso aberto com as opções Resources, Archived, About e Sign out.
Menu suspenso aberto com as opções Resources, Archived, About e Sign out.
caixa-de-dialogo-de-recursos
Caixa de diálogo de recursos com um recurso listado (example.json).
caixa-de-dialogo-de-memos-arquivados
Caixa de diálogo de Memos arquivados com um Memo listado (TAT).

Então pensei. 🤔 Os dados destas caixas de diálogo poderiam ser testados de forma isolada , sem a necessidade de chamadas de rede, caso eu pudesse passar ao frontend a estrutura de dados desejada.

Daí, abri as Dev Tools do navegador, fui para a aba Network, limpei as últimas requisições, e manualmente abri a caixa de diálogo de recursos (Resources) para entender o que tal requisição responderia. Veja a screenshot abaixo.

resources-request
Requisição para os recursos exibida na aba Network das Dev Tools do navegador.

Enfim, na aba Response, eu tinha a estrutura esperada pelo frontend para a criação de minha fixture.

Copiei a resposta, formatei com site https://jsonformatter.curiousconcept.com, alterei alguns dados e então salvei na pasta cypress/fixtures/ com o nome resources.json. A fixture ficou assim.

{
"data": [
{
"id": 1,
"creatorId": 101,
"createdTs": 1671662776,
"updatedTs": 1671662776,
"filename":" example.txt",
"type": "text/plain",
"size": 365644,
"linkedMemoAmount": 0
}
]
}

Daí, foi só criar um teste usando a funcionalidade cy.intercept do Cypress para “mockar” a resposta da API.

O teste ficou assim.

it('opens the resources dialog', () => {
cy.intercept('api/resource', { fixture: 'resources' })
.as('getResources')

cy.get('.user-banner-container svg').click()
cy.contains('button', 'Resources').click()
cy.wait('@getResources')

cy.contains('.dialog-header-container', 'Resources')
.should('be.visible')
cy.get('.dialog-container .resource-container')
.its('length')
.should('eq', 1)
})

E agora, quando executo o teste, a aplicação renderiza na caixa de diálogo de recursos os dados da minha fixture. Veja a imgem abaixo.

cypress-runner
Cypress runner com a aplicação renderizando dados vindos de uma fixture.

Depois, fiz o mesmo para a caixa de diálogo de Memos arquivados.

O código completo dos testes pode ser encontrado nas linhas 44 e 54, a fixture de recursos aqui e a fixture de Memos arquivados aqui.

Ou seja, na próxima vez que você precisar testar o frontend desacoplado da API, você pode buscar os dados para suas fixtures na aba Network das Dev Tools.

Espero que tenhas gostado do post e tenha aprendido algo novo.


Ficou curioso(a) e quer aprender mais sobre automação de testes com Cypress? Conheça os cursos da Escola TAT.


👋  Até a próxima e bons testes!

Um comentário em “Como definir as fixtures para testes de frontend com Cypress

Deixe um comentário