
Neste post vou falar um pouco sobre o que é o [Volta](https://volta.sh/) e porque deixei de usar o [NVM](http://nvm.sh/).

## O que é o Volta

Volta é uma ferramenta de linha de comando que permite instalar e executar qualquer ferramenta JavaScript perfeitamente. Ele garante que todos no projeto usem as mesmas ferramentas, com as mesmas versões.

Para instalar só é necessário executar um comando:

```shell
# install Volta
curl https://get.volta.sh | bash
```

Feito isso, podemos instalar qualquer ferramenta e usar normalmente:

```shell
# install Node
volta install node

# start using Node
node
```

Podemos também instalar uma versão específica:

```shell
volta install node@10
```

Com o comando `volta list all` podemos listar todas as ferramentas e versões instaladas:

```shell
Node runtimes:
    v10.19.0
    v12.19.0 (default)

Package managers:
    Yarn:
        v1.22.10 (default)
```

Quando executamos o comando `volta install` ele baixa a versão e define como default automaticamente, caso você já tenha a versão instalada, ele só define como default.

Também podemos fixar versões em nossos projetos utilizando o comando `volta pin`, por exemplo:

```shell
volta pin node yarn
```

Ele vai adicionar as versões no package.json.

```json
"volta": {
  "node": "12.19.0",
  "yarn": "1.22.10"
}
```

Caso você não tenha alguma dessas versões instaladas, ele baixa automaticamente.

## Por quê deixei de usar o NVM?

Quando ouvi falar sobre o Volta pela primeira vez, a primeira coisa que pensei foi: Não preciso disso, já uso o NVM.

Mesmo assim resolvi dar uma olhada e logo percebi que estava enganado, com o NVM eu conseguia gerenciar versões do Node, com o Volta eu posso fazer isso com qualquer ferramenta.

Além disso, tinham alguns pontos que me incomodavam no NVM:

* Sempre precisava trocar as versões de forma manual, para automatizar isso era necessário fazer algumas configurações no shell e adicionar um arquivo `.nvmrc` no projeto.
* Quando abria o terminal no diretório do projeto demorava um pouco trocar a versão.

Com o Volta a troca de versão é extremamente rápida e não é necessário nenhuma configuração adicional, ele já faz isso automaticamente.

## Conclusão

Este post foi uma breve introdução ao Volta e algumas vantagens que vi em relação ao NVM, se você viu outras vantagens ou desvantagens não deixe de comentar. Abraço!


Gerenciando dependências com Volta

Continuando a série sobre testes, vamos adicionar duas ferramentas ao projeto que ajudam a melhorar a qualidade do código.

Você pode baixar o [repositório](https://github.com/felipecesr/react-com-tdd-na-pratica/tree/master) e fazer o checkout na branch `exercise-05` para continuar de onde paramos.

## Prettier
A primeira ferramenta é o [Prettier](https://prettier.io/), com ele não precisamos nos preocupar com indentação de código, se as aspas devem ser simples ou duplas, etc. Ele formata o código automaticamente mantendo sempre o mesmo padrão.

Para instalar o Prettier execute o comando:

```bash
$ npm i -D prettier
```

Com o Prettier instalado, precisamos criar o arquivo `.prettierrc` e adicionar as [opções](https://prettier.io/docs/en/options.html) desejadas. Você também pode usar o [playground](https://prettier.io/playground/) para ajudar na configuração.

Nesse caso vou criar o arquivo `.prettierrc` na raiz do projeto e adicionar apenas um objeto vazio, para usar as configurações padrão:

```json
{}
```

Adicione o script no `package.json`:

```json
"format": "prettier --write \"src/**/*.{js,jsx}\""
```

Se você executar esse script o Prettier vai formatar todos os arquivos `.js` ou `.jsx` dentro de `src`.

## Extensão para o Visual Studio Code

Para quem usa o [Visual Studio Code](https://code.visualstudio.com/), é possível instalar uma [extensão](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) que facilita ainda mais o uso do Prettier.

Adicione as linhas seguintes no arquivo `settings.json` do Visual Studio Code, para que os arquivos sejam formatados sempre que forem salvos:

```json
{
  "editor.formatOnSave": true,
  "prettier.requireConfig": true
}
```

### Com a extensão instalada, é necessário instalar o Prettier no projeto?

Você pode instalar a extensão e não instalar no projeto, mas se você estiver trabalhando em um projeto a longo prazo que outras pessoas também vão trabalhar nele, é importante instalar o Prettier no projeto, para que todos possam se beneficiar dele, mesmo se não estiverem usando o Visual Studio Code.

## ESLint

O [ESLint](https://eslint.org/) é uma ferramenta incrível de análise de código que ajuda a previnir vários erros.

Para instalar execute o seguinte comando:

```bash
$ npm i -D eslint eslint-config-prettier
```

O ESLint verifica algumas regras de formatação que o Prettier também verifica, para que não tenham conflitos, podemos desabilitar essas regras no ESLint e deixar apenas como responsabilidade do Prettier.

Ao invés de sair desabilitando essas regras uma por uma, instalamos o `eslint-config-prettier` no projeto para desabilitar todas de uma vez.

Crie o arquivo `.eslintrc.json` na raiz do projeto e adicione:

```json
{
  "extends": ["eslint:recommended", "prettier"]
}
```

Podemos adicionar várias configurações pré-definidas nesse Array. A ordem é importante porque as últimas sempre vão sobrescrever as primeiras. Nesse caso o Prettier deve ficar por ultimo porque ele não adiciona nenhuma regra, ele apenas desabilita as regras que são responsabilidade dele.

Para usar a ECMAScript mais recente e features como módulos e JSX, precisamos adicionar mais algumas [configurações](https://eslint.org/docs/user-guide/configuring/language-options):

```json
{
  "extends": ["eslint:recommended", "prettier"],
  "parserOptions": {
    "ecmaVersion": 2021,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  },
  "env": {
    "es6": true,
    "browser": true,
    "jest": true,
    "node": true
  }
}
```

Adicione o seguinte comando no `package.json`:

```json
"lint": "eslint \"src/**/*.{js,jsx}\" --quiet"
```

O `--quiet` faz o ESLint retornar apenas erros, caso tenha algum warning, ele será ignorado.

## Extensão para o Visual Studio Code

O ESLint também conta com uma [extensão](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) pra o Visual Studio Code, para melhorar ainda mais a experiencia do desenvolvedor.

Para que os problemas relatados pelo ESLint sejam corrigidos automaticamente após o arquivo ser salvo, adicione o seguinte no arquivo `settings.json` do Visual Studio Code:

```json
"editor.codeActionsOnSave": {
  "source.fixAll.eslint": true
}
```

## ESLint e React

Quando adicionamos suporte ao JSX, não quer dizer que adicionamos suporte ao React, existem alguns detalhes que o React adiciona no JSX que não são reconhecidos pelo ESLint.

Para que tudo funcione, execute o seguinte comando: 

```bash
$ npm install -D eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-react  
```

Após a intalação, adicione mais algumas configurações no `.eslintrc.json`, para que ele fique assim:

```json
{
  "extends": [
    "eslint:recommended",
    "plugin:import/errors",
    "plugin:react/recommended",
    "plugin:jsx-a11y/recommended",
    "prettier"
  ],
  "rules": {
    "react/prop-types": "off",
    "react/jsx-uses-react": "off",
    "react/react-in-jsx-scope": "off",
    "react/self-closing-comp": "warn"
  },
  "plugins": ["react", "import", "jsx-a11y"],
  "parserOptions": {
    "ecmaVersion": 2021,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  },
  "env": {
    "es6": true,
    "browser": true,
    "jest": true,
    "node": true
  },
  "settings": {
    "react": {
      "version": "detect"
    }
  }
}
```

## ESLint e Hooks

Quando usamos [Hooks](https://reactjs.org/docs/hooks-intro.html) devemos seguir algumas [regras](https://reactjs.org/docs/hooks-rules.html), podemos usar o `eslint-plugin-react-hooks` para nos ajudar com isso.

Para instalar o plugin, execute:

```bash
$ npm install -D eslint-plugin-react-hooks
```

Em seguida adicione ele no `.eslintrc.json`:

```diff
  "plugin:jsx-a11y/recommended",
+ "plugin:react-hooks/recommended",
  "prettier"
```

## Conclusão

Adicionamos duas ferramentas que ajudam a melhorar bastante a qualidade do código. O ESLint faz uma análise estática do código, ajudando a eliminar vários bugs e o Prettier garante que o código seja formatado corretamente.

Quando comecei a usar essas duas ferramentas juntas, sempre ficava com dúvidas durante a instalação, por isso fiz questão de escrever esse artigo e tentei deixar o mais claro possível.

Se esse conteúdo te ajudou ou se ficou alguma dúvida, deixa um comentário. E como de costume o código completo pode ser encontrado nesse [repositório](https://github.com/felipecesr/react-com-tdd-na-pratica/tree/exercise-06). Abraço!



Como configurar o Prettier e ESLint em projetos React

Neste artigo vou explicar como funciona o **Princípio da Responsabilidade Única (SRP)** do **SOLID** e mostrar como aplicá-lo em JavaScript.

## O que é SOLID?

SOLID é um acrônimo de 5 princípios da programação orientada a objetos, são eles:

**[S]**ingle Responsability Principle
**[O]**pen/Closed Principle
**[L]**iskov Substitution Principle
**[I]**nterface Segregation Principle
**[D]**ependency Inversion Principle

Com a aplicação destes princípios podemos obter alguns benefícios, como códigos mais fáceis de manter, adaptar, testar, etc. Além de evitar possíveis problemas como códigos desestruturados, frágeis e duplicados.

## O primeiro princípio

O primeiro princípio do SOLID é o da responsabilidade única ou **SRP**, este princípio define que uma classe deve possuir apenas uma responsabilidade que deve estar totalmente encapsulada dentro dela.

Sua definição formal diz:

> Uma classe deve ter **um, e apenas um**, motivo para ser modificada.

Se uma classe só deve ter um motivo para ser modificada, certamente ela só deve ter uma única responsabilidade.

## Exemplo de violação

Vamos supor que precisamos criar uma classe que faça requisições ao servidor e valide os erros para apresenta-los como um alerta na tela, essa é uma classe que possui mais de uma responsabilidade e claramente viola o SRP. Abaixo segue um exemplo desta classe onde importamos o [SweetAlert2](https://sweetalert2.github.io/) para exibir os alertas de erro:

```javascript
import Swal from 'sweetalert2';

export class HttpClient {
  get(url) {
    return fetch(url, {
      headers: {
        Accept: 'application/json'
      }
    }).then(response => {
      if (response.ok) {
        return response.json();
      } else {
        if (response.status == 401) {
          Swal({
            title: 'Não autorizado',
            type: 'error'
          });
        } else if (response.status == 404) {
          Swal({
            title: 'Não encontrado',
            type: 'warning'
          });
        } else if (response.status == 500) {
          Swal({
            title: 'Erro do Servidor Interno',
            type: 'error'
          });
        } else {
          Swal({
            title: 'Erro desconhecido',
            type: 'info'
          });
        }
      }
    });
  }
}
```

## Resolvendo a violação do SRP

Nesse caso como decidimos importar uma lib para validar o erro antes de que ele seja exibido, podemos separar as responsabilidades em duas classes:

```javascript
import Swal from 'sweetalert2';

export default class ErrorHandler {
  static handle(response) {
    if (response.status == 401) {
      Swal({
        title: 'Não autorizado',
        type: 'error'
      });
    } else if (response.status == 404) {
      Swal({
        title: 'Não encontrado',
        type: 'warning'
      });
    } else if (response.status == 500) {
      Swal({
        title: 'Erro do Servidor Interno',
        type: 'error'
      });
    } else {
      Swal({
        title: 'Erro desconhecido',
        type: 'info'
      });
    }
  }
}
```

```javascript
import ErrorHandler from './error-handler';

export default class HttpClient {
  get(url) {
    return fetch(url, {
      headers: {
        Accept: 'application/json'
      }
    }).then(response => {
      if (response.ok) {
        return response.json();
      } else {
        ErrorHandler.handle(response);
      }
    });
  }
}
```

Dessa forma conseguimos corrigir a violação, dividindo as responsabilidades em classes diferentes.

## Conclusão

Esse é o tipo de princípio que toda aplicação orientada a objetos deve ter, aplicando ele conseguimos criar classes mais coesas e com um acoplamento mais baixo.

Espero que tenham gostado, se tiverem duvidas ou sugestões podem comentar. Abraço!

Princípio da Responsabilidade Única (SRP)

Fala galera! Nos artigos anteriores criamos dois componentes e uma função, testamos cada uma das partes de forma isolada, criando testes que são conhecidos como testes unitários.

Chegou a hora de testar se tudo isso funciona junto, para isso vamos desenvolver uma aplicação simples, criando outro tipo de teste, testes de integração.

## Conhecendo a aplicação

A aplicação é um conversor de moedas, o usuário deve preencher uma quantia e selecionar a moeda dela, quando clicar no botão, a quantia convertida em Real Brasileiro deve ser exibida.

![Wireframe de uma aplicação para converter de moedas](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/o759twvmy48d3q7rj1uk.png)

Para continuar de onde paramos você pode baixar o [repositório](https://github.com/felipecesr/react-com-tdd-na-pratica/tree/master) e fazer um `checkout` na branch `exercise-04`.

Crie o arquivo `App.test.js` dentro de `src` e adicione o seguinte:

```jsx
import { render } from "@testing-library/react";
import App from "./App";

test("shows the amount in brazilian real after submit", () => {
  render(<App />);
});
```

Execute o comando `npm test -- --watch`, e em seguida crie o arquivo `App.js` dentro de `src`.

```jsx
const App = () => null;

export default App;
```

O componente vai funcionar da seguinte forma:

1. Renderiza os componentes `Form` e `Highlight`;
2. O usuário preenche as informações no formulário;
3. As informações são enviadas para uma API que retorna a cotação;
4. A função `multiply` multiplica o valor pela cotação;
5. O valor retornado pela função `multiply` é salvo em um estado e atualizado no componente.

Faça as seguintes alterações no arquivo `App.test.js`:

```jsx
import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import App from "./App";

test("shows the amount in brazilian real after submit", () => {
  render(<App />);

  userEvent.type(screen.getByLabelText(/valor/i), "3000");
  userEvent.selectOptions(screen.getByLabelText(/moeda/i), "USD");
  userEvent.click(screen.getByRole("button", { name: /calcular/i }));

  expect(screen.getByText("14808.9")).toBeInTheDocument();
});
```

Dessa forma, após o `render`, o formulário é preenchido com o `userEvent` e após o clique do botão verificamos se o valor esperado está sendo exibido.

O teste deve retornar o seguinte erro:

```
TestingLibraryElementError: Unable to find a label with the text of: /valor/i
```

Para teste passe, faça as seguintes alterações no arquivo `App.js`:

```jsx
import Form from "./components/Form";
import Highlight from "./components/Highlight";

const App = () => {
  const handleSubmit = () => null;

  return (
    <>
      <Form onSubmit={handleSubmit} />
      <Highlight value="14808.90" />
    </>
  )
};
```

Agora precisamos refatorar o código, para que tenha uma implementação que funcione realmente. Para isso, vamos utilizar a [API de Cotações de Moedas](https://docs.awesomeapi.com.br/api-de-moedas) para obter a cotação.

## Refatoração

Faça as seguintes alterações no arquivo `App.js`.

```jsx
import { useState } from "react";
import Form from "./components/Form";
import Highlight from "./components/Highlight";
import { multiply } from './utils/math'

const App = () => {
  const [value, setValue] = useState(null);

  const handleSubmit = async ({ value, coin }) => {
    const res = await window.fetch(
      `https://economia.awesomeapi.com.br/json/last/${coin}-BRL`
    );
    const data = await res.json();

    const result = multiply(data[`${coin}BRL`].ask, value).toFixed(2);
    setValue(result);
  };

  return (
    <>
      <Form onSubmit={handleSubmit} />
      <Highlight value={value} />
    </>
  )
};
```

Com essas alterações o `handleSubmit` envia os dados, multiplica os valores e armazena o valor em um estado, exatamente como descrevemos antes.

Teoricamente os testes deveriam estar passando, mas não estão, repare que aparecem várias mensagens de erro, e uma delas é essa:

```
TypeError: window.fetch is not a function
```

Isso acontece porque os testes são executados em um ambiente [Node.js](https://nodejs.org/en/), onde não existe uma implementação nativa para a [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API).

Para resolver isso, é necessário usar um polyfill, você pode instalar usando o seguinte comando:

```
npm install --save whatwg-fetch
```

Após a instalação, adicione a seguinte linha no arquivo `jest.config.js`:

```
setupFiles: [require.resolve('whatwg-fetch')],
```

Isso é o suficiente para que possamos usar o `fetch` no ambiente de testes. Se você olhar no terminal, os erros sobre o `fetch` não aparecem mais, o único problema é o teste falhando, mas já vamos resolver isso.

## Testando fluxos assíncronos

Observe onde o teste falha:

```
> 12 |   expect(screen.getByText("14808.90")).toBeInTheDocument();
```

Observe também, que a `div` onde o valor deveria estar, está vazia:

```
<body>
  <div>
    <form>...</form>
    <div />
  </div>
</body>
```

Nenhum valor foi exibido porque o `expect` foi executado antes da requisição ser concluída. Para resolver isso, precisamos fazer duas alterações.

Primeiro, o bloco do teste deve ser assíncrono:

```javascript
test("shows the amount in brazilian real after submit", async () => {
  render(<App />);
```

E segundo, a asserção deve ser feita após a requisição ser concluída para exibir o valor esperado. Podemos usar uma query do tipo `findBy` ao invés de `getBy`, queries desse tipo são assíncronas.

```javascript
expect(await screen.findByText("14808.90")).toBeInTheDocument();
```

## Criando um mock para a Fetch API

Nesse momento, provavelmente o teste está falhando, e eu falo provavelmente porque é algo incerto. Estamos fazendo um requisição para uma API externa, que retorna valores que mudam constantemente.

Nesse tipo de teste, não devemos nos fazer requisições para nenhum serviço externo. Então, ao invés de chamar o `fetch` original, precisamos de algo que funcione no lugar dele, um `mock`.

Dessa vez vamos utilizar o método [`spyOn`](https://jestjs.io/docs/jest-object#jestspyonobject-methodname) dentro de um [`beforeAll`](https://jestjs.io/docs/api#beforeallfn-timeout). Adicione a seguinte linha antes da função `test` no arquivo `App.test.js`:

```javascript
beforeAll(() => jest.spyOn(window, "fetch"));
```

O `spyOn` funciona de forma parecida com o [`jest.fn`](https://jestjs.io/docs/jest-object#jestfnimplementation), ele recebe um objeto, o nome do método que será mocado e adiciona as propriedades de uma [função mock](https://jestjs.io/docs/mock-function-api), permitindo fazer as seguintes asserções:

```javascript
expect(window.fetch).toHaveBeenCalledWith(
  "https://economia.awesomeapi.com.br/json/last/USD-BRL"
);
expect(window.fetch).toHaveBeenCalledTimes(1);
```

Só isso não é o suficiente, porque o `fetch` original continua sendo chamado. Para que isso não aconteça, podemos usar o método [`mockImplementationOnce`](https://jestjs.io/docs/mock-function-api#mockfnmockimplementationoncefn) para definir uma implementação própria para o `fetch`. Adicione o seguinte código após a chamada do `render` no teste:

```javascript
window.fetch.mockImplementationOnce(() => Promise.resolve({
  ok: true,
  json: async () => ({
    USDBRL: { ask: "4.9363" },
  }),
}));
```

Dessa forma, ao invés de chamar o `fetch` original, a função que passamos para o `mockImplementationOnce` é que será chamada. O Jest conta com um método chamado [`mockResolvedValueOnce`](https://jestjs.io/docs/mock-function-api#mockfnmockresolvedvalueoncevalue) que é um "syntactic sugar" para o que acabamos de fazer.

```javascript
window.fetch.mockResolvedValueOnce({
  ok: true,
  json: async () => ({
    USDBRL: { ask: "4.9363" },
  }),
});
```

Feito isso, os testes devem voltar a passar.

## Testando um erro na requisição

Para testar a situação em que a API retorna um erro, podemos criar um teste parecido com o anterior, a diferença nesse caso, é que a API retorna uma mensagem de erro e verificamos se essa mensagem está sendo exibida.

```jsx
test("renders an error message from the server", async () => {
  const testError = "test error";
  render(<App />);

  window.fetch.mockResolvedValueOnce({
    ok: false,
    json: async () => ({ message: testError }),
  });

  userEvent.type(screen.getByLabelText(/valor/i), "3000");
  userEvent.selectOptions(screen.getByLabelText(/moeda/i), "USD");
  userEvent.click(screen.getByRole("button", { name: /calcular/i }));

  expect(await screen.findByRole("alert")).toHaveTextContent(testError);
});
```

Para que o teste passe, faça as seguintes alterações no arquivo `App.js`

```jsx
const App = () => {
  const [value, setValue] = useState(null);
  const [error, setError] = useState(null);

  const handleSubmit = async ({ value, coin }) => {
    const res = await window.fetch(
      `https://economia.awesomeapi.com.br/json/last/${coin}-BRL`
    );
    const data = await res.json();

    if (!res.ok) {
      setError(data.message);
      return;
    }

    const result = multiply(data[`${coin}BRL`].ask, value).toFixed(2);
    setValue(result);
  };

  return (
    <>
      <Form onSubmit={handleSubmit} />
      <Highlight value={value} />
      {error && <div role="alert">{error}</div>}
    </>
  )
};
```

## Conclusão

Nesse artigo, criamos testes de integração para verificar se os componentes que foram desenvolvidos nos artigos anteriores funcionam juntos em uma aplicação, adicionamos suporte para a Fetch API e mais uma vez criamos mocks.

Em aplicações Front-End, testes unitários e testes de integração são bem parecidos, a diferença é que nos testes de integração podemos testar fluxos bem maiores, como páginas ou até mesmo uma aplicação completa, como nesse caso.

Essa série é algo que estou gostando bastante de fazer, espero que este conteúdo esteja ajudando, qualquer coisa não deixa de comentar.

Como de costume, aqui o [repositório](https://github.com/felipecesr/react-com-tdd-na-pratica/tree/exercise-05) para com código feito nesse artigo. Abraço!

Como criar testes de integração em aplicações React

Nesse artigo vamos criar a função `multiply`, seguindo o TDD, que foi explicado em detalhes no primeiro [artigo](https://dev.to/felipecesr/como-criar-um-componente-react-com-tdd-236p). Ela deve receber dois valores e retornar a multiplicação deles.

As principais características de funções puras são, elas não causam efeitos colaterais e retornam o mesmo valor sempre que são chamadas com os mesmos argumentos, isso as torna muito fáceis de testar.

Então chega de conversa e vamos partir para a prática. Baixe o [repositório](https://github.com/felipecesr/react-com-tdd-na-pratica/tree/master) e faça o `checkout` na branch `exercise-03`. Em seguida, crie a pasta `utils` dentro de `src` e dentro dela crie o arquivo `math.test.js`, com as seguintes linhas:

```javascript
test.todo('multiply: returns the multiplication of two numbers')

test.todo('multiply: throws an error when some of the arguments is NaN')
```

E execute o comando `npm test -- --watch` para que o [Jest](https://jestjs.io/) fique observando os arquivos que forem modificados.

O método `todo` permite anotar os testes que queremos escrever no futuro, nesse caso, vamos criar dois testes.

## Testando casos de sucesso

Remova o `todo` do primeiro teste e adicione o seguinte código:

```javascript
test('multiply: returns the multiplication of two numbers', () => {
  expect(multiply(1000, 5.26)).toBe(5260)
})
```

Para fazer o teste passar crie o arquivo `math.js` dentro de `utils`, apenas com o necessário para que o teste passe.

```javascript
export function multiply() {
  return 5260
}
```

Com o teste passando, vamos testar se a função funciona com outros valores, diferente de como foi feito no [desenvolvimento do componente](https://dev.to/felipecesr/como-criar-um-componente-react-com-tdd-236p), não vamos criar outro bloco de teste, ao invés disso, adicione apenas mais um `expect`.

```javascript
import { multiply } from './math'

test('multiply: returns the multiplication of two numbers', () => {
  expect(multiply(1000, 5.26)).toBe(5260)
  expect(multiply(2, 6.24)).toBe(12.48)
})
```

Refatore a função, fazendo o teste passar novamente:

```javascript
export function multiply(a, b) {
  return a * b
}
```

Nesse caso a função também deve funcionar quando receber números em `string`.

```javascript
test('multiply: returns the multiplication of two numbers', () => {
  expect(multiply(1000, 5.26)).toBe(5260)
  expect(multiply(2, 6.24)).toBe(12.48)
  expect(multiply(15, '7.29')).toBe(109.35)
  expect(multiply('3', 5)).toBe(15)
  expect(multiply('5', '5')).toBe(25)
})
```

Com isso, conseguimos garantir que a função `multiply` com funciona com diferentes valores.

## Testando casos de erro

E o que acontece se a função for passada com um valor inválido, por exemplo, um texto ou um booleano?

Para esses casos, podemos fazer a função disparar um erro. Adicione o próximo teste no arquivo `math.test.js`.

```javascript
test('multiply: throws an error when some of the arguments is NaN', () => {
  expect(() => multiply('some invalid value', 'another invalid value')).toThrowError('Arguments must be numbers')
})
```

Note que a chamada para a função `multiply` está dentro de outra função, isso é necessário porque ela vai disparar um erro, nesses casos, se não fizermos dessa forma, o teste não passa.

Para que o teste passe, faça as seguintes alterações no arquivo `math.js`:

```javascript
export function multiply(a, b) {
  if (isNaN(a) || isNaN(b)) {
    throw new Error('Arguments must be numbers')
  }

  return a * b
}
```

Com isso, os testes estão passando, mas observe as mensagens exibidas no terminal:

```
✓ multiply: returns the multiplication of two numbers (5 ms)
✓ multiply: throws an error when some of the arguments is NaN (8 ms)
```

Da forma que estão, os casos que foram testados não ficam claros, podemos melhorar isso com algumas refatorações.

## Refatorando os testes

Para melhorar a forma como os testes são exibidos, podemos criar grupos de teste, usando a função `describe`, ela recebe uma descrição e uma função onde ficam os testes. Faça as seguintes alterações no arquivo `math.test.js`:

```javascript
describe('multiply: returns the multiplication', () => {
  test('of two numbers', () => {
    expect(multiply(1000, 5.26)).toBe(5260)
    expect(multiply(2, 6.24)).toBe(12.48)
    expect(multiply(15, '7.29')).toBe(109.35)
    expect(multiply('3', 5)).toBe(15)
    expect(multiply('5', '5')).toBe(25)
  })
})
```

Observe como os testes são exibidos agora:

```
multiply: returns the multiplication
    ✓ of two numbers (4 ms)
```

Podemos continuar lendo como uma única frase: `returns the multiplication of two numbers`, a diferença é que podemos criar um teste para cada caso e saber exatamente como a função está sendo testada.

```javascript
describe('multiply: returns the multiplication', () => {
  test('of two numbers', () => {
    expect(multiply(1000, 5.26)).toBe(5260)
  })
  
  test('of others two numbers', () => {
    expect(multiply(2, 6.24)).toBe(12.48)
  })

  test('of a number and a string', () => {
    expect(multiply(15, '7.29')).toBe(109.35)
  })

  ...
})
```

Também podemos fazer isso para os casos de erro:

```javascript
describe('multiply: throws an error when', () => {
  test('arguments are texts', () => {
    expect(() => multiply('some invalid value', 'another invalid value')).toThrowError('Arguments must be numbers')
  })
})
```

Conseguimos melhorar as mensagens, mas consequentemente criamos bastante repetição de código, felizmente podemos resolver isso facilmente.

## Removendo código duplicado

Para remover o código duplicado, podemos usar o método `each` que permite repetir o mesmo teste com valores diferentes. O código deve ficar assim:

```javascript
describe('multiply: returns the multiplication', () => {
  const cases = [
    ['of two numbers', 1000, 5.26, 5260],
    ['of others two numbers', 2, 6.24, 12.48],
    ['of a number and a string', 15, '7.29', 109.35],
    ['of a string and a number', '3', 5, 15],
    ['of two strings', '5', '5', 25]
  ]

  test.each(cases)('%s', (_, a, b, expected) => {
    expect(multiply(a, b)).toBe(expected)
  })
})

describe('multiply: throws an error when', () => {
  const cases = [
    [
      'arguments are texts',
      'some invalid value',
      'another invalid value',
      'Arguments must be numbers'
    ]
  ]

  test.each(cases)('%s', (_, a, b, expected) => {
    expect(() => multiply(a, b)).toThrowError(expected)
  })
})
```

Criamos um `Array` de `Arrays` com os argumentos que são passados para o teste. Para mais detalhes sobre o método `each`, você pode consultar a [documentação](https://jestjs.io/docs/api#testeachtablename-fn-timeout).

## Conclusão

Antes de escrever esse artigo eu pensei bastante na função que seria desenvolvida, preferi deixar o mais simples possível para poder focar apenas nos testes e mostrar mais alguns recursos do [Jest](https://jestjs.io/docs/api#testeachtablename-fn-timeout).

Criamos uma função pura, bem simples, mas o que vimos aqui pode ser usado no desenvolvimento de qualquer outra função. E como de costume vou deixar o link do [repositório](https://github.com/felipecesr/react-com-tdd-na-pratica/tree/exercise-04) com o código que foi feito nesse artigo. Abraço!

Como criar funções puras com TDD

Continuando os artigos sobre testes, chegou a hora de adicionar um pouco mais de ação, vamos criar um componente de formulário, onde o usuário vai preencher os campos e clicar em um botão para submeter os dados.

## Escrevendo um teste que falha

Você pode baixar o repositório e fazer o `checkout` na `branch` `exercise-02` para continuar de onde paramos.

Crie o arquivo `Form.test.js` dentro de `src/components` e adicione o seguinte conteúdo:

```jsx
import { render, screen } from "@testing-library/react";
import Form from "./Form";

test("submitting the form calls onSubmit with value and coin", () => {
  render(<Form />);

  screen.getByLabelText(/valor/i);
  screen.getByLabelText(/moeda/i);
  screen.getByRole("button", { name: /calcular/i });
});
```

Já adicionamos queries para obter os campos do formulário, logo após a chamada da função `render`. Existem diferentes tipos de queries, você pode ver com mais detalhes acessando a [documentação](https://testing-library.com/docs/queries/about#types-of-queries).

Também é importante saber que existe uma ordem de [prioridade](https://testing-library.com/docs/queries/about#priority) recomendada para usar as queries. Nesse caso decidi usar [`getByLabelText`](https://testing-library.com/docs/queries/bylabeltext) e [`getByRole`](https://testing-library.com/docs/queries/byrole).

Após criar o teste, crie o arquivo `Form.js`, com o seguinte conteúdo:

```jsx
const Form = () => <form />

export default Form
```

Execute o comando `npm test -- --watch`, dessa forma os testes serão executados sempre que um arquivo for modificado. Agora observe o erro:

```
TestingLibraryElementError: Unable to find a label with the text of: /valor/i

Ignored nodes: comments, <script />, <style />
<body>
  <div>
    <form />
  </div>
</body>

   5 |   render(<Form />);
   6 |
>  7 |   screen.getByLabelText(/valor/i);
```

Sempre que utilizamos queries do tipo `getBy` e o elemento não é encontrado, o teste deve falhar, e além de exibir uma mensagem de erro, também é exibido o `html` do componente, além da linha onde o teste falhou.

## Fazendo o teste passar

Para que o teste passe, precisamos fazer com que esse erro não ocorra mais, e para isso, tudo que precisamos é adicionar o campo valor no formulário.

```jsx
const Form = () => (
  <form>
    <label htmlFor="value">Valor</label>
    <input type="number" id="value" />
  </form>
)
```

Note que o teste continua falhando, mas o erro é outro:

```
>  8 |   screen.getByLabelText(/moeda/i);
```

Adicione o próximo campo do formulário:

```jsx
const Form = () => (
  <form>
    <label htmlFor="value">Valor</label>
    <input type="number" id="value" />

    <label htmlFor="coin">Moeda</label>
    <select id="coin">
      <option value="USD">Dolar Americano</option>
      <option value="EUR">Euro</option>
      <option value="GBP">Libra Esterlina</option>
    </select>
  </form>
)
```

É importante sempre observar bem os erros retornados pelos testes.

```
>  9 |   screen.getByRole("button", { name: /calcular/i });
```

Agora é só adicionar o botão de submit:

```jsx
const Form = () => (
  <form>
    <label htmlFor="value">Valor</label>
    <input type="number" id="value" />

    <label htmlFor="coin">Moeda</label>
    <select id="coin">
      <option value="USD">Dolar Americano</option>
      <option value="EUR">Euro</option>
      <option value="GBP">Libra Esterlina</option>
    </select>

    <button type="submit">Calcular</button>
  </form>
)
```

Com isso o teste já está passando, mas o formulário ainda não envia nenhuma informação.

## Adicionando eventos

O componente `Form` deve receber uma `prop` chamada `onSubmit`, ela será uma função que deve ser chamada com os valores preenchidos no formulário quando ocorrer o evento `submit`.

Faça as seguintes alterações no teste:

```jsx
test("submitting the form calls onSubmit with value and coin", () => {
  const handleSubmit = jest.fn();
  render(<Form onSubmit={handleSubmit} />);
```

O [`jest.fn()`](https://jestjs.io/docs/jest-object#jestfnimplementation) retorna uma [função mock](https://jestjs.io/docs/mock-function-api), esse tipo de função também é conhecido como "spy", e como o próprio nome já diz, eles "espionam" informações secretas sobre funções. Elas possibilitam saber, quantas vezes uma função foi chamada, quais parâmetros ela recebeu, etc.

Com a função `handleSubmit` criada, precisamos preencher o formulário com alguns valores e clicar no botão para submeter o formulário. Para executar o evento de clique precisamos importar o [`fireEvent`](https://testing-library.com/docs/dom-testing-library/api-events) da [Testing Library](https://testing-library.com/). Faça as seguintes alterações no teste:

```jsx
import { render, screen, fireEvent } from "@testing-library/react";
import Form from "./Form";

test("submitting the form calls onSubmit with value and coin", () => {
  const handleSubmit = jest.fn();
  render(<Form onSubmit={handleSubmit} />);

  screen.getByLabelText(/valor/i).value = "3000";
  screen.getByLabelText(/moeda/i).value = "USD";
  fireEvent.click(screen.getByRole("button", { name: /calcular/i }));
});
```

Repare que o teste passa, mas uma mensagem de erro é exibida no terminal:

```
Error: Not implemented: HTMLFormElement.prototype.submit
```

Se você abrir o arquivo `jest.config.js`, poderá ver que a seguinte linha:

```
testEnvironment: "jsdom"
```

O [`jsdom`](https://github.com/jsdom/jsdom) é uma implementação de vários padrões web, para uso com [Node.js](https://nodejs.org/en/). Aqui é onde definimos que o [Jest](https://jestjs.io/) vai usar essa implementação, por isso temos acesso ao DOM no ambiente de teste.

O `jsdom` não conta com o evento `submit` padrão do navegador, e nós também não temos intenção de usá-lo, então para resolver isso, faça a seguinte mudança no componente:

```jsx
const Form = () => {
  const handleSubmit = (e) => {
    e.preventDefault();
  };

  return (
    <form onSubmit={handleSubmit}>
```

Com isso, a mensagem de erro não é mais exibida. Vamos garantir que a função `handleSubmit` seja chamada com as informações corretas quando o formulário é submetido.

Adicione o seguinte `expect` no final do arquivo `Form.test.js`:

```javascript
expect(handleSubmit).toHaveBeenCalledWith({
  value: "3000",
  coin: "USD",
});
```

Com isso o teste volta a falhar, para fazê-lo passar precisamos fazer com que o componente `Form` chame a função que foi passada na `prop` `onSubmit`.

Faça as seguintes alterações no arquivo `Form.js`:

```jsx
const Form = ({ onSubmit }) => {
  const handleSubmit = (e) => {
    e.preventDefault();
    const { value, coin } = e.target.elements;

    onSubmit({
      value: value.value,
      coin: coin.value,
    });
  };
```

Pronto! Com isso o teste volta a passar, você também pode adicionar mais um `expect` para garantir que a função foi chamada apenas uma vez:

```javascript
expect(handleSubmit).toHaveBeenCalledTimes(1);
```

## Melhorando os eventos do usuário

Observe a forma que adicionamos valores e clicamos no botão do formulário:

```jsx
screen.getByLabelText(/valor/i).value = "3000";
screen.getByLabelText(/moeda/i).value = "USD";
fireEvent.click(screen.getByRole("button", { name: /calcular/i }));
```

Adicionamos alguns valores diretamente nos elementos e executamos apenas o evento de `click`.

Quando um usuário está preenchendo um formulário em um navegador e altera um campo, alguns eventos são disparados como `keydown`, `keyup`, `change`, ocorrem diferentes tipos de eventos.

Para que os testes fiquem mais próximos de como um usuário interage com a aplicação, é recomendado usar chamado [`user-event`](https://testing-library.com/docs/ecosystem-user-event/), que também faz parte da Testing Library.

Execute o seguinte comando para instalar o `user-event`:

```bash
npm i -D @testing-library/user-event
```

Agora altere o arquivo `Form.test.js`, para que fique assim:

```jsx
import { render, screen } from "@testing-library/react";
import userEvent from '@testing-library/user-event'
import Form from "./Form";

test("submitting the form calls onSubmit with value and coin", () => {
  const handleSubmit = jest.fn();
  render(<Form onSubmit={handleSubmit} />);

  userEvent.type(screen.getByLabelText(/valor/i), "3000");
  userEvent.selectOptions(screen.getByLabelText(/moeda/i), "USD");
  userEvent.click(screen.getByRole("button", { name: /calcular/i }));

  expect(handleSubmit).toHaveBeenCalledWith({
    value: "3000",
    coin: "USD",
  });
  expect(handleSubmit).toHaveBeenCalledTimes(1);
});
```

## Conclusão

Nesse artigo criamos um formulário, criamos um `mock`, passamos como `prop`, adicionamos eventos, enfim, fizemos bastante coisa. Confesso que foi bem difícil resumir tudo. Como queria fazer algo bem prático, não me aprofundei muito em alguns pontos, mas procurei deixar links em todos eles.

E é isso, mais uma vez espero que o conteúdo tenha ajudado e se tiver alguma dúvida ou sugestão, não deixa de comentar, isso ajuda muito :D.

E como de costume, vou deixar o link do [repositório](https://github.com/felipecesr/react-com-tdd-na-pratica/tree/exercise-03). Valeu!

Como desenvolver um formulário em React com TDD

Fala pessoal! Neste artigo vamos falar sobre [Testing Library](https://testing-library.com/) dando continuidade ao [artigo anterior](https://dev.to/felipecesr/como-criar-um-componente-react-com-tdd-236p). Se quiser pode baixar o [repositório](https://github.com/felipecesr/react-com-tdd-na-pratica/tree/exercise-01-end) para acompanhar o conteúdo.

## O que é?

Como a própria documentação diz, a Testing Library é uma família de pacotes que ajudam a testar componentes de UI do ponto de vista do usuário.

Ele pode ser usado em aplicações com JavaScript puro ou com frameworks, incluindo [React](https://testing-library.com/docs/react-testing-library/intro), [Vue](https://testing-library.com/docs/vue-testing-library/intro) e [Angular](https://testing-library.com/docs/angular-testing-library/intro).

Como estamos usando React, vamos instalar o pacote próprio para ele no nosso projeto:

```bash
npm i -D @testing-library/react
```

Após instalar, altere o arquivo `Highlight.test.js`, removendo a função `render` que criamos e importando a da Testing Library. Você também pode remover o `afterEach`, agora isso é feito por baixo dos panos.

```jsx
import { render } from "@testing-library/react";
import Highlight from "./Highlight";

test("renders a value", () => {
  const value = "3000";
  render(<Highlight value={value} />);
  expect(document.body.textContent).toBe(value);
});

test("renders another value", () => {
  const value = "5000";
  render(<Highlight value={value} />);
  expect(document.body.textContent).toBe(value);
});
```

## Removendo detalhes de implementação

Repare que estamos sempre verificando se o texto da página toda é o valor esperado.

Se houvessem outros elementos com textos na página, seria necessário usar um `querySelector`, com um seletor específico para o elemento.

```javascript
expect(document.querySelector("div").textContent).toBe(value);
```

Isso funcionaria, mas imagine que por algum motivo o elemento deixa de ser uma `div` e passa a ser um `p`.

Sempre que uma mudança desse tipo precisar ser feita você vai alterar o componente e os testes. Esse é um detalhe de implementação que normalmente não faz diferença para o usuário.

Para resolver isso a Testing Library conta com [`queries`](https://testing-library.com/docs/queries/about) que se assemelham a forma como um usuário encontra os elementos na página. Podemos usá-las importando o objeto `screen`, da seguinte forma:

```jsx
import { render, screen } from "@testing-library/react";
import Highlight from "./Highlight";

test("renders a value", () => {
  const value = "3000";
  render(<Highlight value={value} />);
  expect(screen.getByText(value)).toBeTruthy();
});
```

Note que o `expect` mudou um pouco, agora estamos utilizando o método `getByText` para obter um elemento com aquele texto.

Se o elemento for encontrado o teste deve passar, mas repare que passamos a utilizar `toBeTruthy` para fazer a asserção. Será que não tem uma asserção que faça mais sentido?

> Se tiver dúvidas sobre quando um valor é Truthy, esse [link](https://developer.mozilla.org/pt-BR/docs/Glossary/Truthy) do MDN deve te ajudar.

## Adicionando mais asserções

Quando testamos componentes de UI é bem comum verificar se o elemento está na tela, se ele tem um atributo, uma classe, etc.

O [Jest](https://jestjs.io/) não conta com asserções para esse tipo de situação, mas ele nos permite adicioná-las, e a Testing Library conta com uma biblioteca própria para isso, o [`jest-dom`](https://github.com/testing-library/jest-dom).

Execute o seguinte comando:

```bash
npm i -D @testing-library/jest-dom
```

Agora altere o arquivo `Highlight.test.js`, importando o `jest-dom` e utilizando a asserção `toBeInTheDocument`.

```jsx
import { render, screen } from "@testing-library/react";
import "@testing-library/jest-dom";
import Highlight from "./Highlight";

test("renders a value", () => {
  const value = "3000";
  render(<Highlight value={value} />);
  expect(screen.getByText(value)).toBeInTheDocument();
});
```

Dessa forma, fica bem claro que estamos verificando se um elemento está no DOM.

## `jest-dom` global

Nesse exemplo importamos o `jest-dom` direto no arquivo do teste, mas não precisamos fazer dessa forma, podemos importá-lo de forma global.

Para fazer isso, crie o arquivo `setupTests.js` dentro de `src` e adicione a seguinte linha:

```javascript
import "@testing-library/jest-dom/extend-expect";
```

Feito isso, altere o arquivo `jest.config.js` para que fique assim:

```javascript
module.exports = {
  testEnvironment: "jsdom",
  setupFilesAfterEnv: ["<rootDir>/src/setupTests.js"],
};
```

Pronto! Com isso não precisamos mais importar o `jest-dom` nos testes.

## Conclusão

Nesse artigo tivemos um primeiro contato com a Testing Library, simplificamos testes e asserções, removendo detalhes de implementação e deixando-os mais próximos da visão do usuário.

A Testing Library conta com muitos recursos que facilitam os testes, e vamos explorá-los mais ainda nos próximos artigos. Se quiser ver como ficou o código pode acessar esse [repositório](https://github.com/felipecesr/react-com-tdd-na-pratica/tree/exercise-02).

Se tiver alguma dúvida ou sugestão deixa um comentário, bora trocar uma ideia. Abraço!

Simplificando testes com Testing Library

Quando começamos a estudar sobre TDD (Test Driven Development) é comum surgirem algumas dúvidas, por exemplo, o que testar? como escrever testes antes do código de produção?

Este é um artigo bem prático que tem como objetivo acabar com algumas dessas dúvidas se tratando de aplicações React.

## Test Driven Development

O Test Driven Development ou TDD significa Desenvolvimento Orientado a Testes e é uma prática que consiste em um ciclo curto de três passos, conhecidos como Red/Green/Refactor.

![TDD Flow](https://miro.medium.com/max/475/1*5IFu-XBsbzobAK3UxIOq4Q.png)

- **Red**: Primeiro escrevemos um teste que falha, para alguma funcionalidade que ainda será desenvolvida.
- **Green**: Com o teste criado, escrevemos uma solução simples para fazê-lo passar.
- **Refactor**: Por último refatoramos, ou seja, melhoramos o código.

Esse ciclo deve se repetir várias vezes durante todo o desenvolvimento.

Tendo isso em mente podemos ver como esse ciclo funciona na prática.

## Escrevendo um teste que falha

Para acompanhar o desenvolvimento você pode baixar o [repositório](https://github.com/felipecesr/react-com-tdd-na-pratica/tree/master) e fazer o checkout na branch `exercise-01-start`.

Após baixar o código, crie a pasta `src/components` e adicione o arquivo `Highlight.test.js` com o seguinte conteúdo:

```jsx
import ReactDOM from "react-dom";
import Highlight from "./Highlight";

test("renders a value", () => {
  const container = document.createElement("div");
  document.body.appendChild(container);

  ReactDOM.render(<Highlight />, container);

  expect(document.body.textContent).toBe("3000");
});
```

A função `test` recebe uma descrição do teste como primeiro parâmetro. É uma boa prática sempre começar com um verbo no presente. O segundo parâmetro é uma função anônima com o código do teste.

Uma `const` chamada `container` tem como valor uma `div`, que é o elemento onde o componente será renderizado.

O método `render` do `ReactDOM` é utilizado para renderizar o componente.

Por último, é feita uma chamada a função `expect`, ela fornece uma [lista de métodos](https://jestjs.io/docs/expect#methods) que nos permitem fazer diferentes asserções. Neste caso, verificamos se o `textContent` da página é `3000`.

Execute o comando `npm test`, veja que o teste está falhando, isso já era esperado, porque ainda estamos no primeiro passo do ciclo.

## Fazendo o teste passar

Agora crie o arquivo `Highlight.js` dentro de `src/components`, com o seguinte conteúdo:

```jsx
const Highlight = () => <div>3000</div>;

export default Highlight;
```

Por enquanto não precisamos de nada além disso para que o teste passe.

## Refatorando o código

Adicionamos um valor "na mão", apenas para o teste passar, mas vamos precisar que o componente funcione com outros valores, para isso vamos fazer a seguinte alteração no teste:

```jsx
ReactDOM.render(<Highlight value="3000" />, container);
```

E logo em seguida no componente:

```jsx
const Highlight = ({ value }) => <div>{value}</div>;
```

Fizemos essas mudanças na intenção ter um código melhor, que funcione com diferentes valores, mas quem garante que funciona?

## Repetindo o ciclo

Para garantir que o componente está funcionando como esperado, podemos repetir o ciclo escrevendo outro teste. Adicione o seguinte código no arquivo `Highlight.test.js`:

```jsx
test("renders another value", () => {
  const container = document.createElement("div");
  document.body.appendChild(container);

  ReactDOM.render(<Highlight value="5000" />, container);

  expect(document.body.textContent).toBe("5000");
});
```

Execute os testes novamente. Note que o segundo teste falha e com um erro bem estranho:

```
Expected substring: "5000"
Received string:    "30005000"
```

Isso acontece porque adicionamos um elemento ao `body` e não o removemos após a execução do primeiro teste.

## Removendo efeitos colaterais

Para que o teste passe, devemos garantir que o que foi feito em um não interfira no resultado do outro. Podemos remover todos os elementos do `body` após cada teste. A função `afterEach` do Jest permite fazer isso de uma forma bem simples. Adicione o seguinte código antes dos testes:

```javascript
afterEach(() => {
  document.body.innerHTML = "";
});
```

## Removendo código duplicado

Se olharmos bem o arquivo de teste, podemos ver claramente que alguns itens se repetem. Essa é a hora em que devemos resistir a tentação de passar para o próximo componente e trabalhar duro para deixar nosso código o mais limpo possível.

Crie a seguinte função no arquivo de testes:

```javascript
function render(component) {
  const container = document.createElement("div");
  document.body.appendChild(container);

  ReactDOM.render(component, container);
}
```

Ela contém o código que se repete nos dois testes. Com essa função, podemos refatorar os testes, tornando-os mais simples:

```jsx
test("renders a value", () => {
  const value = "3000"; // Arrange
  render(<Highlight value={value} />); // Act
  expect(document.body.textContent).toBe(value); // Assert
});

test("renders another value", () => {
  const value = "5000"; // Arrange
  render(<Highlight value={value} />); // Act
  expect(document.body.textContent).toBe(value); // Assert
});
```

Para saber se um teste é bom, você deve ser capaz de identificar cada uma das seguintes etapas:

- **Arrange**: Faz o setup das dependências de teste
- **Act**: Executa o código de produção em teste
- **Assert**: Verifica se as expectativas são atendidas

Mas isso não é tudo, podemos deixar os testes ainda melhores, garantindo que eles atendam alguns requisitos:

- Sejam descritivos
- Independentes de outros testes
- Não tenham efeitos colaterais

O ideal é sempre buscar atender todos esses requisitos, você vai ganhar muito com isso e provavelmente evitar algumas dores de cabeça no futuro.

## Conclusão

Nesse artigo desenvolvemos um componente React seguindo o TDD, fiz o possível para que não ficasse muito longo.

Se esse conteúdo te ajudou ou se ficou alguma dúvida, deixa um comentário, isso me ajuda a saber se devo criar mais conteúdo desse tipo.

Ah! O código completo pode ser encontrado nesse [repositório](https://github.com/felipecesr/react-com-tdd-na-pratica/tree/exercise-01-end). Abraço!


Como criar um componente React com TDD

Aprenda como criar um componente de lista em React com desenvolvimento guiado por testes.

## Introdução

Dando continuidade ao [artigo anterior](https://felipecesar.dev/escrevendo-um-componente-react-com-tdd), onde criamos o componente `UserInfo`, neste artigo vamos criar o componente `UserList` que vai receber um `array` com nomes de usuários e renderizar uma lista com cada um deles.

Além disso, também vamos começar a usar uma ferramenta que não usamos no artigo anterior, o [Testing Library](https://testing-library.com/).

## Testing Library

O Testing Library, de uma forma bem resumida, é uma familia de pacotes que nos permite interagir diretamente com DOM por meio de queries que ajudam a testar nossas aplicações de um ponto de vista semelhante ao do usuário, reduzindo detalhes de implementação.

Ele pode ser usado em aplicações com JavaScript puro ou com frameworks, incluindo [React](https://testing-library.com/docs/react-testing-library/intro), [Vue](https://testing-library.com/docs/vue-testing-library/intro) e [Angular](https://testing-library.com/docs/angular-testing-library/intro).

Como estamos usando React, vamos instalar o pacote próprio para ele no nosso projeto.

```shell
npm install --save-dev @testing-library/react
```

Após a instalação, vamos criar um arquivo chamado `UserList.test.js`. Dessa vez não vamos criar um método render, vamos importá-lo diretamente do Testing Library.

```javascript
import { render } from '@testing-library/react';
```

## Renderizando a lista

Com o arquivo `UserList.test.js` criado, vamos escrever nosso primeiro teste.

```javascript
describe("UserList", () => {
  it("renders multiple users in ul element", () => {
    const users = [
      { id: 1, name: "Matthew Murdock" },
      { id: 2, name: "Frank Castle" }
    ];

    const { container } = render(<UserList users={users} />);

    expect(container.querySelector("ul")).not.toBeNull();
    expect(container.querySelector("ul").children).toHaveLength(2);
  });
});
```

Repare que o `render` do Testing Library nos permite usar o `container` de forma semelhante a que criamos antes.

Lembrando que quando estamos desenvolvendo com TDD precisamos seguir todo o fluxo dele, então vamos executar nosso teste e vê-lo falhar.

```shell
● UserList › renders multiple users in ul element

ReferenceError: UserList is not defined
```

Para corrigir isso, vamos criar o arquivo `UserList.js`, retornando apenas `null` por enquanto.

```javascript
export const UserList = () => null;
```

E importá-lo dentro do teste.

```javascript
import { UserList } from '../src/UserList';
```

Ao retornar `null` dessa forma, deixamos de receber um erro do React e passamos a receber uma mensagem de erro mais amigável.

```shell
expect(received).not.toBeNull()

Received: null

   9 | const { container } = render(<UserList users={users} />);
  10 |
> 11 | expect(container.querySelector("ul")).not.toBeNull();
     |                                           ^
```

Vamos fazer o mínimo necessário para o teste passar.

```javascript
const List = () => <ul />;
```

Ao executar o teste novamente, recebemos outro erro.

```shell
Expected length: 2
Received length: 0
Received object: []

  10 |
  11 | expect(container.querySelector("ul")).not.toBeNull();
> 12 | expect(container.querySelector("ul").children).toHaveLength(2);
     |
```

Como temos mais de um `expect` podemos ver em qual deles o teste está falhando.

Vamos usar a função `map` para renderizar todos os itens da lista.

```javascript
const List = ({ users }) => (
  <ul>
    {users.map(() => <div />)}
  </ul>
);
```

Você pode estar se perguntando por quê usei `div` ao invés de `li`, por enquanto isso não vai fazer diferença no resultado do teste, podemos usar os próximos testes para verificar se os itens são `li`.

Após essa alteração o teste deve passar, mas com um aviso que não devemos ignorar.

```shell
console.error node_modules/react/cjs/react.development.js:175
Warning: Each child in a list should have a unique "key" prop.
```

Para remover esse aviso, podemos fazer o que ele diz e adicionar a `prop` nos itens da lista.

```javascript
<ul>
  {users.map(user => <div key={user.id} />)}
</ul>
```

## Especificando os itens da lista

Agora vamos preencher os itens da lista que acabamos de criar. Primeiro, vamos criar outro teste.

```javascript
it("renders each user in a li", () => {
  const users = [
    { id: 1, name: "Matthew Murdock" },
    { id: 2, name: "Frank Castle" }
  ];

  const { container } = render(<UserList users={users} />);
  const listItems = container.querySelectorAll("li");


  expect(listItems).toHaveLength(2);
  expect(listItems[0].textContent).toEqual("Matthew Murdock");
  expect(listItems[1].textContent).toEqual("Frank Castle");
});
```

Ao executá-lo devemos receber o seguinte erro.

```shell
Expected length: 2
Received length: 0
Received object: []

  25 | const listItems = container.querySelectorAll("li");
  26 |
> 27 | expect(listItems).toHaveLength(2);
     |                   ^
```

Como não existe nenhum elemento `li` o teste não vai passar, vamos corrigir isso.

```javascript
<ul>
  {users.map(user => <li key={user.id} />)}
</ul>
```

Recebemos outro erro após executar novamente o teste.

```shell
Expected: "Matthew Murdock"
Received: ""

  26 |
  27 | expect(listItems).toHaveLength(2);
> 28 | expect(listItems[0].textContent).toEqual("Matthew Murdock");
     |                                  ^
```

Para corrigi-lo, precisamos exibir o nome do usuário no item da lista.

```javascript
<ul>
  {users.map(user => (
    <li key={user.id}>{user.name}</li>
  ))}
</ul>
```

Pronto! Temos o nosso componente de lista funcionando e coberto por testes, só falta refatorar nosso código.

## Refatorando

Não sei se você reparou, mas instalamos o Testing Library para melhorar a forma como escrevemos os testes. Até agora não vimos nenhuma diferença, simplesmente deixamos de criar um método `render` para usar um que já está pronto.

Para deixar nossos testes mais próximos da forma como o usuário interage com a aplicação, podemos usar as queries que o Testing Library nos dá.

O Testing Library conta com queries que podemos usar para interagir diretamente com o DOM, `ByLabelText`, `ByPlaceholderText` e `ByText`, são algumas delas, além disso, cada query tem variantes como `getBy` e `getAllBy`. Na [documentação](https://testing-library.com/docs/dom-testing-library/api-queries) você pode ver exatamente o que cada uma delas faz.

No primeiro teste, vamos usar a query `getByRole`, com ela podemos buscar um elemento do DOM a partir de uma **ARIA role**.

```javascript
it("renders multiple users in list", () => {
  const users = [
    { id: 1, name: "Matthew Murdock" },
    { id: 2, name: "Frank Castle" }
  ];

  const { getByRole } = render(<UserList users={users} />);

  expect(getByRole("list")).not.toBeNull();
  expect(getByRole("list").children).toHaveLength(2);
});
```

Quando usamos o `getByRole` não passamos o seletor do elemento, ao invés disso passamos a `role` dele. Cada elemento possui uma `role` padrão, que deve ser usada caso não tenha nenhuma outra definida com por meio de um atributo.

Como isso torna nosso código mais próximo da forma que o usuário interage com a aplicação?

Podemos pensar que estamos dizendo para o usuário checar se uma existe uma lista e se ela tem dois itens, independente de ser um `ul` ou `ol`, não precisamos desses detalhes de implementação no teste.

Você pode conferir a `role` de cada elemento nessa [lista](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles).

No segundo teste, podemos usar a query `getByAllRole` para obter todos os itens da lista.

```javascript
it("renders each user in a list item", () => {
  const users = [
    { id: 1, name: "Matthew Murdock" },
    { id: 2, name: "Frank Castle" }
  ];

  const { getAllByRole } = render(<UserList users={users} />);
  const listItems = getAllByRole("listitem");

  expect(listItems).toHaveLength(2);
  expect(listItems[0].textContent).toEqual("Matthew Murdock");
  expect(listItems[1].textContent).toEqual("Frank Castle");
});
```

Por fim, movemos o `array` de usuários para o topo da função `describe`, deixando o código mais limpo e sem repetições.

```javascript
describe("UserList", () => {
  const users = [
    { id: 1, name: "Matthew Murdock" },
    { id: 2, name: "Frank Castle" }
  ];

  it("renders multiple users in list", () => {
    const { getByRole } = render(<UserList users={users} />);
    expect(getByRole("list")).not.toBeNull();
    expect(getByRole("list").children).toHaveLength(2);
  });

  it("renders each user in a list item", () => {
    const { getAllByRole } = render(<UserList users={users} />);
    const listItems = getAllByRole("listitem");
    expect(listItems).toHaveLength(2);
    expect(listItems[0].textContent).toEqual("Matthew Murdock");
    expect(listItems[1].textContent).toEqual("Frank Castle");
  });
});
```

## Conclusão

Neste artigo, criamos um componente de lista com TDD e ainda podemos aprender um pouco sobre Testing Library, nos próximos vamos explorar um pouco mais essa lib. Se tiverem dúvidas ou sugestões não deixem de comentar. Abraço!


React com TDD: Renderizando uma lista


Como funciona o desenvolvimento guiado por testes na criação de um componente React.

## Introdução

Nesse artigo vamos ver um passo a passo de como criar um componente React seguindo o TDD. Não vou me aprofundar muito, então é importante que você tenha algum conhecimento em React e Jest. Antes de começar a prática vamos relembrar como funciona o TDD.

## Test-driven Development

![TDD Flow](https://miro.medium.com/max/475/1*5IFu-XBsbzobAK3UxIOq4Q.png)

O Test-driven Development (TDD) é uma técnica que guia o desenvolvimento de software por meio de testes.

Basicamente seguimos um fluxo de desenvolvimento que possui 3 passos:

- **Red**: Primeiro escrevemos um teste que falha, para alguma funcionalidade que ainda será desenvolvida.
- **Green**: Com o teste criado, escrevemos uma solução simples para fazê-lo passar.
- **Refactor**: Por último refatoramos, ou seja, melhoramos o código.

Tendo isso em mente, podemos começar a desenvolver nosso componente passando por cada uma dessas etapas.

## Escrevendo um teste que falha

Vamos criar um componente bem simples, ele recebe um nome de usuário e exibe.

Como o desenvolvimento é guiado por testes, começamos criando o arquivo de teste `UserInfo.test.js`.

Dentro desse arquivo ficarão os testes do nosso componente. Vamos adicionar o seguinte código:

```javascript
import React from 'react'
import ReactDOM from 'react-dom'

describe('UserInfo', () => {
  it('renders the user name', () => {})
})
```

A função `describe` define uma suíte de testes. Para componentes React é uma boa prática atribuir a suíte de testes o mesmo nome do componente que será testado.

A função `it` define um único teste. O primeiro argumento é a descrição do teste e é uma boa prática sempre começar com um verbo no presente.

Você pode ler as descrições das funções `describe` e `it` como uma única frase: **UserInfo renders the user name (UserInfo renderiza o nome de usuário)**. Essa é uma boa prática que deve ser seguida sempre que possível.

Dentro do bloco `it` vamos criar uma `const` chamada `user` com um atributo `name` que armazena o nome do usuário. Depois criamos outra `const` chamada `component` que armazena o componente `UserInfo` com a prop `name`.

```jsx
const user = { name: 'Walter White' }
const component = <UserInfo name={user.name} />
```

Vamos criar uma `const` chamada `container` e dentro dela vamos criar uma `div`. Essa `div` é onde o componente será renderizado.

```javascript
const container = document.createElement('div')
```

Depois chamamos o método `ReactDOM.render` passando o componente que queremos renderizar e o elemento HTML onde ele será renderizado.

```javascript
ReactDOM.render(component, container)
```

Por fim chamamos a função `expect` que recebe um valor e compara com um valor esperado. Nesse caso o valor esperado é **`Walter White`** e o valor recebido é `container.textContent`.

```javascript
expect(container.textContent).toMatch('Walter White')
```

Quando executarmos o teste ele vai dar o seguinte erro:

```shell
ReferenceError: UserInfo is not defined
   5 |   it('renders the user name', () => {
   6 |     const user = { name: 'Walter White' };
>  7 |     const component = <UserInfo name={user.name} />;
```

Não definimos o componente `UserInfo` de propósito, primeiro escrevemos um teste que falha lembra?

## Fazendo o teste passar

Dentro do arquivo UserInfo.js vamos criar o nosso componente da maneira mais simples possível para o teste passar.

```javascript
import React from 'react'

export const UserInfo = () => <div>Walter White</div>
```

Não se assuste! Como eu disse, a solução deve ser a **mais simples possível**.

E importá-lo dentro do arquivo `UserInfo.test.js`.

```javascript
import { UserInfo } from './UserInfo'
```

Ao executar novamente nosso teste vemos que ele passou:

```
PASS  test/UserInfo.test.js

UserInfo
✓ renders the user name (21ms)
```

Show! Nosso teste está passando, mas e se quisermos usar esse componente com outro valor?

Para chegar em uma implementação real, precisamos adicionar mais testes, esse processo é chamado de **triangulação**. Então vamos escrever mais um teste:

```javascript
it('renders another user name', () => {
  const user = { name: 'Jesse Pinkman' }
  const component = <UserInfo name={user.name} />
  const container = document.createElement('div')
  ReactDOM.render(component, container)
  expect(container.textContent).toMatch('Jesse Pinkman')
})
```

Ao executar novamente nosso teste, vemos que ele volta a falhar, mas com um erro diferente dessa vez:

```
● UserInfo › renders another user name

  expect(received).toMatch(expected)

  Expected substring: "Jesse Pinkman"
  Received string:    "Walter White"
```

Precisamos alterar nosso componente de uma forma que os dois testes passem:

```javascript
export const UserInfo = ({ name }) => <div>{name}</div>
```

Show! Agora quando rodamos nossos testes eles passam.

```
PASS  test/UserInfo.test.js

UserInfo
✓ renders the user name (26ms)
✓ renders another user name (2ms)
```

Mas será que nosso código não poderia ficar melhor?

## Refatoração

Essa é a hora em que devemos resistir a tentação de passar para o próximo componente e trabalhar duro para deixar nosso código, tanto de produção quanto o de teste, o mais limpo possível.

Se reparamos bem no nosso arquivo `UserInfo.test.js`, podemos ver claramente que alguns itens se repetem e isso não é uma boa prática.

```jsx{3,4,5,6,12,13,14,15}
describe('UserInfo', () => {
  it('renders the user name', () => {
    const user = { name: 'Walter White' }
    const component = <UserInfo name={user.name} />
    const container = document.createElement('div')
    ReactDOM.render(component, container)

    expect(container.textContent).toMatch('Walter White')
  })

  it('renders another user name', () => {
    const user = { name: 'Jesse Pinkman' }
    const component = <UserInfo name={user.name} />
    const container = document.createElement('div')
    ReactDOM.render(component, container)

    expect(container.textContent).toMatch('Jesse Pinkman')
  })
})
```

Para melhorar esse cenário podemos fazer algumas melhorias no código do nosso teste:

Ambos os testes usam as mesmas duas variáveis: `container` e `user`. Podemos mover essas declarações para o topo da função `describe`, deixando para fazer as atribuições dentro dos testes, isso significa que precisaremos usar `let` ao invés de `const`:

```javascript
let container, user
```

Usamos a função `createElement` da mesma forma em ambos os testes, nesse tipo de caso podemos usar a função `beforeEach` que será executada antes de cada teste:

```javascript
beforeEach(() => {
  container = document.createElement('div')
})
```

Também usamos o método `ReactDOM.render` em ambos os testes, a diferença é que precisamos passar o componente `UserInfo` como parâmetro dentro de cada teste. Nesse caso podemos criar uma função `render`:

```javascript
const render = (component) => ReactDOM.render(component, container)
```

Com isso nosso teste deve ficar assim:

```javascript
it('renders the user name', () => {
  user = { name: 'Walter White' }
  render(<UserInfo name={user.name} />)
  expect(container.textContent).toMatch('Walter White')
})
```

Dividimos nosso teste em três seções distintas:

- **Arrange**: Configura dependências de teste
- **Act**: Executa o código de produção em teste
- **Assert**: Verifica as expectativas são atendidas

Com isso, conseguimos deixar nosso teste bem mais limpo e conciso. Abaixo podemos ver como ficou o arquivo final:

```javascript
describe('UserInfo', () => {
  let container, user

  beforeEach(() => {
    container = document.createElement('div')
  })

  const render = (component) => ReactDOM.render(component, container)

  it('renders the user name', () => {
    user = { name: 'Walter White' }
    render(<UserInfo name={user.name} />)
    expect(container.textContent).toMatch('Walter White')
  })

  it('renders another user name', () => {
    user = { name: 'Jesse Pinkman' }
    render(<UserInfo name={user.name} />)
    expect(container.textContent).toMatch('Jesse Pinkman')
  })
})
```

## Conclusão

É isso, tentei resumir bastante para que o artigo não ficasse muito longo, espero que tenham gostado, se tiverem dúvidas ou sugestões não deixem de comentar. Abraço!


Felipe César

Últimos posts