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 meus cursos no Udemy.


👋  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

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s