[pt-BR] Conheça a melhor forma de escrever testes no seu front-end - #2
Published: 2022-02-07 14:38:15


Como vimos na Parte 1, testar detalhes de implementação no front-end pode ser uma armadilha que pode acabar mascarando erros gerando falso-positivos ou falso-negativos ou até mesmo atrapalhando a produtividade por serem muito frágeis.

Vamos então abordar de maneira prática um caminho para se pensar em testes no front-end de forma que eles se tornem mais confiáveis e com mais qualidade.

### O que será abordado:
- Testando Casos de Uso
- Cobertura de Código
- Cobertura de Casos de Uso
- Quando a Cobertura de Código oculta os Casos de Uso

# Testando Casos de Uso

> "Quanto mais seus testes se assemelham à forma como seu software é usado, mais confiança eles podem lhe dar." - Kent C. Dodds

Essa é a natureza dos testes de casos de uso, pensar em escrever testes que atendam a forma que nossos dois usuários** (usuário-final e usuário-desenvolvedor) usam e interagem com nossa aplicação.

***ver Detalhes de implementação da [parte 1](https://dev.to/dxwebster/pt-br-testes-sao-fundamentais-mas-como-saber-o-que-testar-parte-1-13f)*


Escrevemos testes para ter certeza de que nosso aplicativo funcionará quando o usuário os usar e principalmente melhorar a confiança da aplicação.

> "Pense menos no código que você está testando e mais nos casos de uso que o código suporta." - Kent C. Dodds

## Cobertura de Código

*Cobertura de código* é a métrica que nos mostra quais linhas do nosso código estão rodando durante o teste. Vamos utilizar esse código como exemplo:

```js
function verificaArray(array) {
  if (Array.isArray(array)) return array
  else if (!array) return []
  else return [array]
}
```
Sem incluir teste para essa função, o relatório vai indicar que 0% de *Cobertura de código* nos dando a ideia de quanta parte do código ainda falta cobrir.

O relatório de *Cobertura de código* não diz exatamente qual a importância da função `verificaArray` ou nem mesmo diz os casos de uso que ela atende.

Mas quando consideramos a aplicação inteira, mesmo o relatório de *Cobertura de código* não nos dando uma a visão completa, ele nos ajuda a identificar quais testes poderiam ser adicionados para atender os casos de uso da aplicação.

# Cobertura de Casos de Uso

A *Cobertura de Casos de Uso* nos diz quantos casos de uso nosso teste atende. Voltando ao código de exemplo, podemos identificar o primeiro **caso de uso** da função `verificaArray`:

- "Retorna um array se o argumento for um array".

*Obs: Há uma convenção de escrever os títulos dos testes em inglês, entretanto neste estudo, vou escrevê-los em português-BR por uma questão didática, beleza?*

```js
test('Retorna um array se o argumento for um array', () => {
  expect(verificaArray(['Elefante', 'Girafa']))
  .toEqual(['Elefante', 'Girafa'])
})
```
E com esse teste escrito, nosso relatório de *Cobertura de Código* vai parecer com algo do tipo:
 
```js
function verificaArray(array) {          // coberto
  if (Array.isArray(array)) return array // coberto
  else if (!array) return []
  else return [array]
}
```

Assim, se olharmos para as linhas que faltam, vamos concluir que são mais dois **casos de Uso** que faltam ser cobertos:

- "Retorna um array vazio se o argumento tiver um valor falso"
- "Retorna um array se o argumento não for um array e não for falso"

Vamos adicionar os testes para esses **casos de uso**, e ver como isso afeta a *Cobertura de Código*

```js
test(
'Retorna um array vazio se o argumento tiver um valor falso', () => {
   expect(verificaArray()).toEqual([])
})

test(
`Retorna um array se o argumento não for um array e não for falso`,
() => {
  expect(verificaArray('Leopardo')).toEqual(['Leopardo'])
})
```
Cobertura:

```js
function verificaArray(array) {          // coberto
  if (Array.isArray(array)) return array // coberto
  else if (!array) return []             // coberto
  else return [array]                    // coberto
}
```

Ótimo! Agora temos 100% de cobertura de código, mas também 100% de cobertura de casos de uso e podemos confiar que, enquanto não mudarmos os casos de uso dessa função, nossos testes vão continuar passando.


## Quando a cobertura de código oculta os casos de uso

As vezes, o relatório de *Cobertura de código* pode indicar 100% de cobertura, mas não 100% de cobertura de casos de uso.

Esse é o motivo que é bom ter a prática de pensar em todos os casos de uso possíveis antes mesmo de começar a escrever os testes.

Por exemplo, vamos imaginar que a function `verificaArray` foi implementada desse jeito:

```js
function verificaArray(array) {         
  if (Array.isArray(array)) return array
  else return [array].filter(Boolean)                   
}
```

Com isso, nós temos 100% de cobertura com apenas os 2 casos de uso:

- Retorna um array se o argumento for um array
- Retorna um array se o argumento não for um array

Entretanto, se olharmos para o relatório de *Cobertura de caso de uso*, podemos perceber que está faltando um caso de uso:

- Retorna um array vazio se o argumento tiver um valor falso

E isso é um mau sinal, pois mesmo se o usuário user a função `verificaArray` sem passar nenhum argumento, os testes vão continuar passando, mas o código vai quebrar.

E essa é justamente uma das razões que implementamos testes, garantir que o código continue atendendo aos casos de uso que desejamos incluir. 

Por exemplo, se um outro dev remover o `.filter(Boolean)`, os testes ainda continuam passando, mas qualquer código que dependia do resultado da function como sendo "falso", vai quebrar. 

### 👉 Continue lendo na [parte 3](https://dev.to/dxwebster/pt-br-testes-sao-fundamentais-mas-como-saber-o-que-testar-parte-3-5da0)

---

**Referências:**
"How to know what to test" - Kent C. Dodds 
[https://kentcdodds.com/blog/how-to-know-what-to-test](https://kentcdodds.com/blog/how-to-know-what-to-test)
"Avoid the Test User" - Kent C. Dodds 
[https://kentcdodds.com/blog/avoid-the-test-user](https://kentcdodds.com/blog/avoid-the-test-user)
"Testing Implementation Details" - Kent C. Dodds 
[https://kentcdodds.com/blog/testing-implementation-details](https://kentcdodds.com/blog/testing-implementation-details)