Bem-vindo! Fico feliz em vê-lo na sexta parte da minha série de resumos da Vuejs Amsterdam Conference 2022, na qual compartilho um resumo de todas as palestras com você.

Você pode ler minha série de Resumos da JSWorld Conference 2022 (em quatro partes) aqui , onde resumi todas as palestras do primeiro dia. Você também pode encontrar as palestras anteriores da conferência Vue Amsterdam 2022 em meu blog.

(Recorrente) Introdução

Depois de dois anos e meio, a JSWorld e a Vue Amsterdam Conference estiveram de volta ao Theatre Amsterdam entre 1 e 3 de junho, e tive a oportunidade de participar desta conferência pela primeira vez. Aprendi muitas coisas, conheci muitas pessoas maravilhosas, conversei com grandes desenvolvedores e me diverti muito. No primeiro dia foi realizado o JSWorld Conference, e no segundo e terceiro dias, o Vue Amsterdam.

A conferência estava cheia de informações com grandes oradores, cada um dos quais me ensinou algo valioso. Todos queriam compartilhar seus conhecimentos e informações com outros desenvolvedores. Então pensei que seria ótimo se eu pudesse continuar a compartilhá-lo e ajudar outras pessoas a usá-lo.

A princípio, tentei compartilhar algumas anotações ou slides, mas senti que não era bom o suficiente, pelo menos não tão bom quanto o que o palestrante compartilhou comigo. Então decidi rever cada palestra, me aprofundar nelas, pesquisar, fazer anotações e combiná-las com seus slides e até com suas palavras exatas em sua fala e depois compartilhar com vocês para que o que eu compartilho com vocês seja pelo menos no mesmo nível do que aprendi com eles.

Um ponto muito importante

Tudo o que você lê nesses poucos artigos é resultado do esforço e do tempo do próprio palestrante, e eu apenas tentei aprendê-los para poder transformá-los nesses artigos. Mesmo muitas das frases escritas nesses artigos são exatamente o que eles disseram ou o que escreveram no Slides. Isso significa que se você aprender algo novo, é por causa de seus esforços. (Então, se você vir alguma desinformação culpe eles, não eu, certo? xD)

Por último, mas não menos importante, posso não me aprofundar em todos os detalhes técnicos ou codificações ao vivo em alguns dos discursos. Mas se você estiver interessado e precisar de mais informações, me avise e tentarei escrever um artigo mais detalhado separadamente. Além disso, não se esqueça de verificar o Twitter/Linkedin deles.

Aqui você pode encontrar o programa da conferência.

É uma (teste) armadilha! Armadilhas de teste comuns e como resolvê-las

Ramona Schwering - Desenvolvedora de software na shopware

“É uma armadilha” - uma chamada ou sentimento com o qual todos podemos estar familiarizados, não apenas quando se trata de Guerra nas Estrelas. Está sinalizando um momento súbito de perceber um perigo iminente.

Esta situação é uma excelente alegoria para uma realização desagradável no teste. Imagine ter as melhores intenções quando se trata de testes, mas ainda acabar com os testes falhando em entregar qualquer valor?

Testes que estão se sentindo como uma dor de lidar?

Ao escrever testes de front-end, existem muitas armadilhas no caminho. Em suma, eles podem levar a uma manutenção ruim, tempo de execução lento e, na pior das hipóteses, testes nos quais você não pode confiar.

Mas o pior ponto de dor são aqueles testes que lhe dão novo valor e resultado porque são esquisitos. Você tem uma construção que às vezes passa e às vezes falha e você não fez nada no meio.

Pontos de dor

Você pode ter certeza de que o teste tem muitas vantagens e vantagens, mas todas essas coisas maravilhosas podem ser ofuscadas por pontos problemáticos causados por vários motivos. Todas as coisas que você fez com as melhores intenções, mas a longo prazo ou até antes, acabaram sendo dolorosas ou cansativas.

Por exemplo, testes lentos podem acabar com a diversão. Imagine que você tem sua solicitação de pull e deseja que ela seja mesclada, mas precisa esperar horas ou talvez dias para que o pipeline seja finalmente concluído.

Pior ainda são os testes que são dolorosos de manter. Você pensa em seu eu passado e pergunta: O que você fez com este teste? Qual era o propósito?! O que você achou sobre isso? Ou outros membros da equipe que estão fazendo perguntas sobre o que você fez no passado e você não tem ideia.

Mas o pior ponto de dor são aqueles testes que lhe dão novo valor e resultado porque são esquisitos. Você tem uma construção que às vezes passa e às vezes falha e você não fez nada no meio.

Testes Simples

Não precisa ser assim. Uma das mentalidades e regras de ouro mais importantes nas melhores práticas de teste de JavaScript é Simples.

Os testes devem ser projetados simples e simples em todos os casos. Em testes de unidade, testes de integração e testes de ponta a ponta, mantenha tudo simples.

Nosso objetivo deve ser que alguém seja capaz de entender seu teste e obter sua intenção instantaneamente sem pensar nisso.

Tente apontar para um design de teste simples, o que significa apenas testar o quanto for necessário e usar poucas ou nenhuma abstração.

armadilhas

Vejamos a primeira Armadilha.

 describe('deprecated.plugin', () => { it('should throw error',() => { … }); });

Deve gerar um erro se o plug-in obsoleto estiver em uso.

Quando você olha para o título - deve gerar um erro - você não sabe o que ele quer realizar. Mas a regra de ouro diz que você deve saber instantaneamente o que está fazendo.

Podemos torná-lo mais compreensível com a “Regra das Três Partes”. O título do teste deve conter três coisas:

1. O que está sendo testado
2. Em que circunstâncias deve ser testado
3. Qual é o resultado esperado

Com essa regra em mente, nosso teste ficará assim:

 describe('deprecated.plugin', () => { it('Property: Should throw an errorif the deprecated prop is used', () => { … }); });

A próxima armadilha pode ser a estrutura de teste:

 describe('Context menu', () => { it('should open the context menu on click', async () => { const wrapper = createWrapper(); expect(wrapper.vm).toBeTruthy(); await wrapper.trigger('click'); const selector = '.sw-context-menu'; expect(wrapper.find(selector).isVisible()).toBeTruthy(); }); });

Nesse caso, declarações, ações e asserções são escritas em todos os lugares, sem nenhuma estrutura clara. Especialmente em testes maiores, isso pode ser uma dor enorme. Podemos torná-lo mais estruturado com padrão AAA. Você divide seu teste em três partes:

1. Organizar: Tudo o que diz respeito à configuração do cenário que o teste pretende simular.
2. Ações: Executar sua unidade no teste e executar as etapas para chegar ao estado de resultados.
3. Assert: onde você pode fazer as asserções e verificar seu cenário de teste.

É assim que nosso teste se parece com o padrão AAA:

 describe('Context menu', () => { it('should open the context menu on click', () => { // Arrange const wrapper = createWrapper(); const selector = '.sw-context-menu'; // Act await wrapper.trigger('click'); // Assert expect(wrapper.vm).toBeTruthy(); expect(wrapper.find(selector).isVisible()).toBeTruthy(); }); });

Isso parece muito melhor!

Mas há um problema. Pense novamente em nosso caso de teste. É um menu de contexto e está oculto por padrão. Portanto, precisamos abri-lo para interagir com ele. Mas isso significa que precisamos fazer uma afirmação para garantir que ela esteja aberta antes do ato. Não destrói o padrão?

Se estivermos testando o DOM, às vezes precisamos verificar os estados antes e depois. Então, vamos dar uma olhada neste padrão de outra perspectiva.

• …organizar meu teste == o que me foi dado .
• …agir no meu teste == quando algo acontece.
• …afirme os resultados == algo acontece , então isso é o que eu espero como resultado.

Este é um padrão retirado do desenvolvimento dirigido por comportamento: Dado - Quando - Então

Nosso teste anterior com o uso deste padrão:

 describe('Context menu', () => { it('should open the context menu on click', () => { // Given const contextButtonSelector = 'sw-context-button'; const contextMenuSelector = '.sw-context-menu'; // When let contextMenu = wrapper.find(contextMenuSelector); expect(contextMenu.isVisible()).toBe(false); const contextButton = wrapper.find(contextButtonSelector); await contextButton.trigger('click'); // Then contextMenu = wrapper.find(contextMenuSelector); expect(contextMenu.isVisible()).toBe(true); }); });

Teste E2E

Evite usar espaços reservados e use nomenclatura realista o máximo possível.

 it('should create and read product', () => { … cy.get('.sw-field—product-name').type('T-Shirt Ackbar'); cy.get('.sw-select-product__select_manufacturer') .type('Space Company'); … });

Se você não quiser criar milhares de nomes, talvez possa usar o faker ou outras ferramentas para gerar alguns dados fictícios ou, se estiver de acordo com as leis e seu projeto, importe-os do estado de produção. Apenas certifique-se de que seu teste permaneça compreensível e fácil de ler e que você saiba o que ele faz.

Vamos dar uma olhada no mesmo teste para a próxima armadilha, que são os seletores.

Se você refatorar seu aplicativo e alterar algumas classes - o que é comum - isso pode fazer com que seu teste falhe e, neste caso, o teste falha sem um bug presente em seu aplicativo - o que é chamado de falso negativo, não fornecendo nenhum relatório confiável de seu aplicativo. app porque não está quebrado, apenas sua implementação foi alterada.

Olhe para os seletores que você deve! Em outras palavras, você não deve testar detalhes de implementação. Em vez disso, pense em usar coisas que um usuário chamaria a atenção e navegar em seu aplicativo. Por exemplo, algum texto dentro de sua página. Melhor ainda, use seletores que não são tão propensos a mudanças, como atributos de dados. Você pode até chamá-lo, por exemplo, de cypress data-cy=”submit” para saber instantaneamente que ele é destinado a testes.

Por último, mas não menos importante, não use tempos de espera fixos.

 Cypress.Commands.add('typeSingleSelect', { prevSubject: 'element', }, (subject, value, selector) => { … cy.wait(500); cy.get(`${selector} input`) .type(value); });

Por um lado, isso pode tornar seu teste muito lento se um caso de teste for executado tantas vezes. Pode ser ainda pior quando seu aplicativo está sendo usado em um hardware mais fraco. Nesse caso, você pode precisar de mais do que 500 ms de correção.

Existem algumas soluções para isso, por exemplo, aguardar as alterações na interface do usuário, como um spinner de carregamento desaparecer ou uma animação parar ou algo aparecer.

Ou, melhor ainda, aguarde as solicitações e respostas da API.

Os testes existem como um assistente para você, não como um obstáculo. Eles devem parecer uma rotina, não como resolver uma fórmula matemática complexa.

Fim da Sexta Palestra

Espero que tenham gostado dessa parte e que ela seja tão valiosa para vocês quanto foi para mim. Nos próximos dias, compartilharei o restante das palestras com você. Fique ligado…

Publicado também aqui .