Onde os testes são executados

Os testes automatizados geralmente podem ser executados executando um script manualmente ou usando uma auxiliar de um framework de testes, geralmente chamado de executor de testes, para encontrar e executar provas. No entanto, nem sempre você quer ter que executar os scripts manualmente. Há diversas maneiras de executar testes que podem fornecer feedback e confiança em diferentes pontos do ciclo de vida de desenvolvimento.

Script de pré-requisito

Os projetos da Web geralmente têm um arquivo de configuração, o arquivo package.json, que é configurado por npm, pnpm, Bun ou semelhante. Esse arquivo de configuração contém dependências do projeto e outras informações, bem como scripts auxiliares. Esses scripts auxiliares podem incluir como criar, executar ou testar seu projeto.

Dentro de package.json, você precisa adicionar um script chamado test que descreva como executar seus testes. Isso é importante porque, ao usar npm ou um ferramenta, a ferramenta "test" script tem um significado especial. Esse script pode apontar para um único arquivo que gera uma exceção: algo como node tests.js, mas recomendamos usá-lo para apontar executor de testes estabelecido.

Se você estiver usando o Vitest como executor de testes, o package.json vai ficar assim:

{
  "name": "example-project",
  "scripts": {
    "start": "node server.js",
    "test": "vitest --run"
  }
}

Executar npm test com esse arquivo executa o conjunto padrão de testes do Vitest uma vez. Em Vitest. O padrão é encontrar todos os arquivos que terminam com ".test.js" ou semelhantes e executá-las. Dependendo da sua escolhido, o comando pode ser um pouco diferente.

Optamos por usar o Vitest, uma estrutura de teste cada vez mais popular, para ao longo do curso. Você pode ler mais sobre essa decisão no Vitest como um executor de testes. No entanto, é importante lembrar que frameworks e executores de teste, mesmo entre idiomas, tendem a ter um vernacular comum.

Invocação de teste manual

Acionar manualmente seus testes automatizados (como o uso de npm test no exemplo anterior) pode ser prático enquanto você está trabalhando ativamente em uma base de código. Escrever testes para um recurso enquanto desenvolve esse recurso pode ajudar você a de como o recurso deve funcionar. Isso toca no conceito de desenvolvimento orientado a testes (TDD, na sigla em inglês).

Os executores de teste normalmente têm um comando curto que pode ser invocado para executar todos os seus testes e possivelmente um modo de observação que os executa novamente enquanto você salva para resolvê-los com rapidez. Todas essas opções são úteis para o desenvolvimento de um novo recurso projetada para facilitar a criação de um novo recurso, de seus testes, ou ambos, tudo com feedback rápido. O Vitest, por exemplo, opera no modo de observação por padrão: o comando vitest vai monitorar as mudanças e executar novamente todos os testes que encontrar. Qa deixe isso aberto em outra janela enquanto escreve testes. Assim, é possível obter feedback rápido sobre seus testes à medida que os desenvolve.

Alguns executores também permitem marcar testes como only no código. Se o código incluir testes only, apenas esses testes serão acionados quando você os executar. tornando o desenvolvimento de testes mais rápido e fácil de resolver. Mesmo que todas as suas sejam concluídos rapidamente, o uso de only pode reduzir a sobrecarga e remover a distração da execução de testes não relacionados ao recurso ou teste em que você está trabalhando.

Para pequenos projetos, especialmente projetos com apenas um desenvolvedor, também é possível e querem desenvolver o hábito de executar regularmente todo o pacote de testes da base de código. Isso é especialmente útil se seus testes forem pequenos e concluídos rapidamente (em nenhum mais do que alguns segundos para todos os testes) para que você possa verificar se tudo está funcionando antes de você prosseguir.

Executar testes como parte do pré-envio ou da revisão

Muitos projetos optam por confirmar se uma base de código está funcionando corretamente quando será mesclado de volta na ramificação main. Se você é iniciante em testes, contribuíram para projetos de código aberto no passado, você deve ter notado parte do processo de solicitação de envio (PR) confirma que todos os testes do projeto passar, o que significa que sua nova contribuição não afetou negativamente o em um projeto que já existe.

Se você executar os testes localmente, o repositório on-line do projeto (por exemplo, GitHub ou outro serviço de hospedagem de código) não saberão que os testes estão sendo aprovados, então executar testes como uma tarefa de pré-envio deixa claro para todos os colaboradores que e tudo está funcionando.

O GitHub, por exemplo, chama-se "verificações de status" que você pode adicionar por GitHub Actions. As ações do GitHub são É uma espécie de teste: cada etapa precisa ter êxito (não falhar nem gerar Error) para que a ação seja transmitida. É possível aplicar ações a todos os PRs de um projeto, e um projeto pode exigir que as ações sejam transmitidas antes de contribuir com o código. do GitHub a ação padrão do Node.js executa npm test como uma das etapas.

Essa abordagem aos testes tenta garantir que a base de código esteja sempre "verde" por não aceitar códigos que não executam os testes com sucesso.

Executar testes como parte da integração contínua

Depois que a PR verde for aceita, a maioria das bases de código vai executar testes novamente com base no a ramificação main do seu projeto, em vez da RP anterior. Isso pode acontecer imediatamente ou regularmente (por exemplo, de hora em hora ou todas as noites). Esses os resultados geralmente são mostrados como parte de um painel de integração contínua (CI) mostra a integridade geral do projeto.

Essa etapa de CI pode parecer redundante, especialmente para projetos com bases de código pequenas. foram aprovados durante a revisão. Portanto, eles devem ser aprovados quando houver uma alteração. No entanto, isso nem sempre é verdade. Seus testes podem falhar repentinamente, mesmo após serem concluídos produzindo resultados ecológicos. Alguns motivos para isso incluem:

• Várias mudanças foram aceitas "de uma só vez", às vezes conhecida como condição de corrida, e afetam umas às outras de maneira sutil e não testada.
• Seus testes não são reproduzíveis ou são "instáveis" códigos, eles podem transmitir e falham sem alterações no código.
  • Isso pode ocorrer se você depender de sistemas externos à sua base de código. Para um proxy, imagine o teste se Math.random() > 0.05. Isso falha aleatoriamente em 5% do período.
• Alguns testes são muito caros ou caros para serem executados em todos os PRs, como testes de ponta a ponta Testes. Saiba mais em Tipos de testes automatizados. e podem falhar ao longo do tempo sem sempre alertar.

Nenhum desses problemas é impossível de superar, mas vale a pena perceber que testes e desenvolvimento de software em geral, nunca será algo exato ciência

Um intervalo na reversão

Quando os testes são executados como parte da integração contínua, e mesmo quando eles são como parte de uma verificação de status, é possível que a versão fique em um estado "vermelho" ou outro que significa que os testes estão falhando. Como mencionado anteriormente, isso pode acontecer por vários motivos, incluindo disputas no teste ou testes instáveis.

Para projetos menores, seu instinto pode ser tratá-lo como uma crise. Parar reverter ou reverter a alteração ofensiva e voltar a uma configuração bom estado. Essa pode ser uma abordagem válida, mas é importante lembrar que os testes (e o software em geral) são um meio para um fim, não um objetivo por conta própria. Seu objetivo provavelmente é escrever um software, e não fazer com que todos os testes sejam aprovados. Em vez disso, avance seguindo a alteração interruptiva com outro que corrige os testes com falha.

Por outro lado, talvez você já tenha visto ou trabalhado em grandes projetos existentes em um estado perpetuamente corrompido. Ou pior, o projeto grande tem um teste instável que quebras com frequência suficiente para causar fadiga do alarme em desenvolvedores. Muitas vezes, esse é um problema existente para os líderes resolverem: esses os testes podem até ser desativados porque são considerados como "atrapalhar desenvolvimento.

Não há uma solução rápida para isso, mas pode ser útil se tornar mais confiante ao escrever (aprimoramento) e reduzir o escopo dos testes (simplificação) para que e falhas podem ser identificadas com mais facilidade. Um número maior de testes de componentes ou testes de integração. Saiba mais em Tipos de testes automatizados testes) podem dar mais confiança do que um enorme teste completo que é difícil de manter e tenta fazer tudo de uma só vez.

Recursos

• Quais são os benefícios de ter builds noturnos

Teste seu conhecimento