|
|
|
| [Home](home) | [Escopo e Cronograma](escopo) | [Processo](processo) | [Design/Mockups](design_mockups) | [Configuração](configuracao) | [**Arquitetura**](arquitetura) | [Código](codigo) | [BD](banco_dados) | [Qualidade](qualidade) | [Utilização](utilizacao) | [Gitflow](gitflow) | [Testes](testes)
|
|
|
|
| :----------: | :---------------------------: | :------------------: | :--------------: | :--------------------------: | :----------------------------: | :--------------: | :---------------: | :--------------------: | :----------------------: | :----------------: | ------- |
|
|
|
|
|
|
|
|
# Testes
|
|
|
|
|
|
|
|
## Descrição
|
|
|
|
|
|
|
|
Aqui iremos abordar os testes pensados para os projetos.
|
|
|
|
|
|
|
|
## Sumário
|
|
|
|
|
|
|
|
- [Frontend - Dashboard](#frontend-dashboard)
|
|
|
|
- [O que testar](#o-que-testar)
|
|
|
|
- [Como testar](#como-testar)
|
|
|
|
- [Jest](#jest)
|
|
|
|
- [Criando um teste](#criando-um-teste)
|
|
|
|
- [Executando o teste](#criando-um-teste)
|
|
|
|
- [Gerando cobertura de testes](#criando-um-teste)
|
|
|
|
|
|
|
|
# Frontend Dashboard
|
|
|
|
|
|
|
|
## **O que testar**
|
|
|
|
|
|
|
|
Geralmente páginas e componentes que contenham alguma lógica ou regras são ótimos candidatos a testes. Por exemplo: um formulário de cadastro. Podemos testar se os campos foram preenchidos corretamente ou até mesmo se o usuário chegou na próxima tela.
|
|
|
|
|
|
|
|
## **Como testar**
|
|
|
|
|
|
|
|
Injetamos um valor apropriado no componente ou página em questão e no final, fazemos um teste para verificar se o elemento que foi renderizado na [DOM](https://www.w3schools.com/whatis/whatis_htmldom.asp) está com as propriedades que esperamos (estados de erros, por exemplo). Neste mesmo contexto (formulário de cadastro com erros de validação), podemos verificar se a função **registrar** não foi disparada nenhuma vez durante o fluxo, pois como há erros de validação, o número de chamadas deverá ser igual a 0.
|
|
|
|
|
|
|
|
## **Jest**
|
|
|
|
|
|
|
|
Para tanto, iremos utilizar de um framework muito conhecido no ecossistema javascript: o [Jest](https://jestjs.io/pt-BR/). Trata-se de uma biblioteca poderosa com foco em testes unitários, nos possibilitando iniciar o projeto com testes desde o início.
|
|
|
|
|
|
|
|
## **Criando um teste**
|
|
|
|
|
|
|
|
Para criarmos um teste, é preciso que o mesmo esteja no diretório `src\__tests__`. A nomenclatura segue um padrão de nome da página ou componente com o sufixo `.spec.ts`, pois é com base nele que o **jest** sabe o que é um arquivo de teste ou não. Exemplo: `ExampleComponent.spec.ts`. Deverá ficar assim:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
O processo para criarmos um teste é fácil. Começamos declarando a função `describe`, passando dois argumentos: o primeiro é o nome da suíte que estamos testando e o segundo é um ***callback*** retornando todos os cenários que iremos testar.
|
|
|
|
|
|
|
|
|
|
|
|
Em seguida, utilizamos a função `it` para descrevermos um possível cenário. Uma boa convenção é utilizar o início da descrição sempre com `should be` seguido do contexto. Exemplo: `should be able to render an message`.
|
|
|
|
|
|
|
|
|
|
|
|
Vamos fazer algumas observações nesste trecho:
|
|
|
|
- 1 - Na linha `7`, estamos mandando renderizar (`render`) um componente (`ExampleComponent`), passando o atributo `message` como *hello world*. Note que o render nos devolve várias funções:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A que iremos utilizar, é a `getByTestId`. É importante notar que este atributo está definido como `data-testid='component'` no componente:
|
|
|
|
|
|
|
|
|
|
|
|
- 2 - Na linha `9` estamos, estamos recuperando o elemento renderizado na DOM cujo id é `component`. Na linha `10` estamos recuperando o primeiro elemento filho do componente `ExampleComponent`, nesse caso o `message`. E por fim, na linha `12`, estamos falando que a gente espera (`expect`) que o resultado (`result`) seja igual (`toEqual`) à *hello world*.
|
|
|
|
|
|
|
|
## **Executando o teste**
|
|
|
|
|
|
|
|
Para executarmos um teste, podemos especificar o caminho da suíte, ou apenas rodar um `test all`:
|
|
|
|
- executando uma suíte: ```npm run test ExampleComponent.spec.tsx```
|
|
|
|
- executando todos os testes: ```npm run test```
|
|
|
|
|
|
|
|
Teremos o seguinte resultado:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## **Gerando cobertura de testes**
|
|
|
|
|
|
|
|
Podemos gerar cobertura de testes para sabermos o que já foi testado e o que ainda precisa (e se precisa) ser testado. Basta utilizarmos o comando ```npm run -- test --coverage --watchAll=false```. Teremos o seguinte resultado no terminal:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Além do mais, podemos acessar a pasta `coverage` que foi gerada na raíz do nosso projeto e abrir a cobertura via web:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Após copiar o caminho do arquivo, basta colarmos no navegador para termos o resultado:
|
|
|
|
|
|
|
|
 |
|
|
\ No newline at end of file |
