DEV Community: Felipe César

Como configurar o Prettier e ESLint em projetos React

Felipe César — Sat, 17 Jul 2021 17:03:06 +0000

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 e fazer o checkout na branch exercise-05 para continuar de onde paramos.

Prettier

A primeira ferramenta é o Prettier, 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:

$ npm i -D prettier

Com o Prettier instalado, precisamos criar o arquivo .prettierrc e adicionar as opções desejadas. Você também pode usar o 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:

{}

Adicione o script no package.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, é possível instalar uma extensão 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:

{
  "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 é uma ferramenta incrível de análise de código que ajuda a previnir vários erros.

Para instalar execute o seguinte comando:

$ 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:

{
  "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:

{
  "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:

"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 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:

"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:

$ 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:

{
  "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 devemos seguir algumas regras, podemos usar o eslint-plugin-react-hooks para nos ajudar com isso.

Para instalar o plugin, execute:

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

Em seguida adicione ele no .eslintrc.json:

  "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. Abraço!

Princípio da Responsabilidade Única (SRP)

Felipe César — Fri, 16 Jul 2021 16:55:06 +0000

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 para exibir os alertas de erro:

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:

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'
      });
    }
  }
}

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!

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

Felipe César — Mon, 12 Jul 2021 20:23:16 +0000

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.

Para continuar de onde paramos você pode baixar o repositório e fazer um checkout na branch exercise-04.

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

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.

const App = () => null;

export default App;

O componente vai funcionar da seguinte forma:

Renderiza os componentes Form e Highlight;
O usuário preenche as informações no formulário;
As informações são enviadas para uma API que retorna a cotação;
A função multiply multiplica o valor pela cotação;
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:

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:

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 para obter a cotação.

Refatoração

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

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, onde não existe uma implementação nativa para a 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:

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.

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 dentro de um beforeAll. Adicione a seguinte linha antes da função test no arquivo App.test.js:

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

O spyOn funciona de forma parecida com o jest.fn, ele recebe um objeto, o nome do método que será mocado e adiciona as propriedades de uma função mock, permitindo fazer as seguintes asserções:

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 para definir uma implementação própria para o fetch. Adicione o seguinte código após a chamada do render no teste:

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 que é um "syntactic sugar" para o que acabamos de fazer.

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.

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

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> : null}
    </>
  )
};

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 para com código feito nesse artigo. Abraço!

Como criar funções puras com TDD

Felipe César — Sat, 10 Jul 2021 17:01:06 +0000

Nesse artigo vamos criar a função multiply, seguindo o TDD, que foi explicado em detalhes no primeiro artigo. 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 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:

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 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:

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.

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, não vamos criar outro bloco de teste, ao invés disso, adicione apenas mais um expect.

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:

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

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

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.

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:

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:

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.

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:

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:

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.

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.

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 com o código que foi feito nesse artigo. Abraço!

Como desenvolver um formulário em React com TDD

Felipe César — Thu, 08 Jul 2021 13:12:36 +0000

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:

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.

Também é importante saber que existe uma ordem de prioridade recomendada para usar as queries. Nesse caso decidi usar getByLabelText e getByRole.

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

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.

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:

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:

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:

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

O jest.fn() retorna uma função mock, 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 da Testing Library. Faça as seguintes alterações no teste:

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 a seguinte linha:

testEnvironment: "jsdom"

O jsdom é uma implementação de vários padrões web, para uso com Node.js. Aqui é onde definimos que o Jest 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:

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:

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:

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:

expect(handleSubmit).toHaveBeenCalledTimes(1);

Melhorando os eventos do usuário

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

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, que também faz parte da Testing Library.

Execute o seguinte comando para instalar o user-event:

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

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

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. Valeu!

Simplificando testes com Testing Library

Felipe César — Tue, 06 Jul 2021 16:23:37 +0000

Fala pessoal! Neste artigo vamos falar sobre Testing Library dando continuidade ao artigo anterior. Se quiser pode baixar o repositório 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, Vue e Angular.

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

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.

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.

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 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:

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 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 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.

Execute o seguinte comando:

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

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

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:

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

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

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.

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

Como criar um componente React com TDD

Felipe César — Tue, 06 Jul 2021 02:19:19 +0000

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.

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 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:

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 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:

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:

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

E logo em seguida no componente:

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:

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:

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:

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:

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. Abraço!

Managing dependencies with Volta

Felipe César — Thu, 22 Oct 2020 12:52:02 +0000

In this post I will talk about Volta and why I stopped using NVM.

What is Volta?

Volta is a command-line tool that allows you to install and execute any JavaScript tool perfectly. It ensures everyone in the project has the same tools, whit same versions.

To install you just need to run a command:

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

Then, we can install any tool and use it normally:

# install Node
volta install node

# start using Node
node

You can pin versions in your projects as well:

volta pin node yarn

This command will add the versions in an object in package.json.

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

If you don't have this versions, Volta will download them on the fly for you.

Why did I stop using NVM?

When I heard about Volta for the first time, I thought: I don't need that, I've already using NVM.

Even so, I decided to take a look at Volta and realised that I was wrong. With NVM I was able to managing versions of Node, with Volta I can do this for any tool.

Furthermore, NVM has some points that bothered me:

I always needed to change the versions manually. To automate this it was necessary to add some settings to the shell, as well as add a .nvmrc file to the project.
There is a delay to change versions. With Volta this change is really faster and no-additional settings is required, it does it automatically.

Conclusion

This post was a brief introduction to Volta and some pros that I see compared to NVM, if you saw another pros or cons tell me in the comments.

DEV Community: Felipe César

Como configurar o Prettier e ESLint em projetos React

Prettier

Extensão para o Visual Studio Code

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

ESLint

Extensão para o Visual Studio Code

ESLint e React

ESLint e Hooks

Conclusão

Princípio da Responsabilidade Única (SRP)

O que é SOLID?

O primeiro princípio

Exemplo de violação

Resolvendo a violação do SRP

Conclusão

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

Conhecendo a aplicação

Refatoração

Testando fluxos assíncronos

Criando um mock para a Fetch API

Testando um erro na requisição

Conclusão

Como criar funções puras com TDD

Testando casos de sucesso

Testando casos de erro

Refatorando os testes

Removendo código duplicado

Conclusão

Como desenvolver um formulário em React com TDD

Escrevendo um teste que falha

Fazendo o teste passar

Adicionando eventos

Melhorando os eventos do usuário

Conclusão

Simplificando testes com Testing Library

O que é?

Removendo detalhes de implementação

Adicionando mais asserções

jest-dom global

Conclusão

Como criar um componente React com TDD

Test Driven Development

Escrevendo um teste que falha

Fazendo o teste passar

Refatorando o código

Repetindo o ciclo

Removendo efeitos colaterais

Removendo código duplicado

Conclusão

Managing dependencies with Volta

What is Volta?

Why did I stop using NVM?

Conclusion

`jest-dom` global