{"componentChunkName":"component---src-templates-docs-js","path":"/docs/testing-recipes.html","result":{"data":{"markdownRemark":{"html":"

Padrões de teste comuns para componentes React.

\n
\n

Nota:

\n

Esta página assume que você está utilizando o Jest como executor de testes. Se você está utilizando um executor de testes diferente, pode ser necessário ajustar a API, mas no geral o desenho da solução provavelmente será o mesmo. Leia mais detalhes sobre como configurar um ambiente de testes na página Ambientes de Teste.

\n
\n

Nessa página, nós iremos primeiramente usar componentes funcionais. Entretanto, essas estratégias não dependem desses detalhes de implementação e também funcionam em componentes de classe.

\n\n
\n

Detalhamento da configuração

\n

Para cada teste, nós geralmente queremos renderizar nossa árvore React para um elemento do DOM que está atrelado a um documento. Isso é importante para que ele receba eventos do DOM. Quando o teste finaliza, nós queremos realizar uma “limpeza” e desmontar a árvore do documento.

\n

Um jeito comum de se realizar isso é usar a combinação dos blocos beforeEach e afterEach para que eles sempre sejam executados e isolem o bloco de teste.

\n
import { unmountComponentAtNode } from \"react-dom\";\n\nlet container = null;\nbeforeEach(() => {\n  // Configura um elemento do DOM como alvo do teste\n  container = document.createElement(\"div\");\n  document.body.appendChild(container);\n});\n\nafterEach(() => {\n  // Limpar ao sair\n  unmountComponentAtNode(container);\n  container.remove();\n  container = null;\n});
\n

Você pode utilizar um padrão diferente, mas tenha em mente que queremos executar uma limpeza mesmo que o teste falhe. Caso contrário, os testes podem impactar outros, alterando o comportamento. Isso faz com que eles sejam difíceis de serem depurados.

\n
\n

act()

\n

Quando estiver escrevendo testes de UI, tarefas como renderização, eventos de usuário ou busca de testes podem ser considerados como “unidades” de interação com a interface do usuário. react-dom/test-utils provê um auxiliar chamado act() que garante que todas as atualizações relacionadas a esses “usuários” estejam sendo processadas e aplicadas ao DOM antes que você faça alguma declaração de testes.

\n
act(() => {\n  // renderizar componentes\n});\n// fazer declarações de testes
\n

Isso ajuda seus testes a serem executados próximo do que os usuários experimentariam quando estiverem usando sua aplicação. O restante dos exemplos utilizam a função act() para ter essas garantias.

\n

Você pode achar que utilizar o act() diretamente um pouco verboso demais. Para evitar um pouco do boilerplate, você pode usar uma biblioteca como a React Testing Library, cujo as funções auxiliares são encapsuladas com o act().

\n
\n

Nota:

\n

O nome act vem do padrão Arrange-Act-Assert.

\n
\n
\n

Renderizando

\n

Popularmente, você deseja testar se um componente renderiza corretamente dado a prop recebida. Considere um componente simples que renderiza uma mensagem baseado em uma prop:

\n
// hello.js\n\nimport React from \"react\";\n\nexport default function Hello(props) {\n  if (props.name) {\n    return <h1>Hello, {props.name}!</h1>;\n  } else {\n    return <span>Hey, stranger</span>;\n  }\n}
\n

Nós podemos criar o seguinte teste para esse componente:

\n
// hello.test.js\n\nimport React from \"react\";\nimport { render, unmountComponentAtNode } from \"react-dom\";\nimport { act } from \"react-dom/test-utils\";\n\nimport Hello from \"./hello\";\n\nlet container = null;\nbeforeEach(() => {\n  // configurar o elemento do DOM como o alvo da renderização\n  container = document.createElement(\"div\");\n  document.body.appendChild(container);\n});\n\nafterEach(() => {\n  // Limpar ao sair\n  unmountComponentAtNode(container);\n  container.remove();\n  container = null;\n});\n\nit(\"renders with or without a name\", () => {\n  act(() => {    render(<Hello />, container);  });  expect(container.textContent).toBe(\"Hey, stranger\");\n  act(() => {\n    render(<Hello name=\"Jenny\" />, container);\n  });\n  expect(container.textContent).toBe(\"Hello, Jenny!\");\n\n  act(() => {\n    render(<Hello name=\"Margaret\" />, container);\n  });\n  expect(container.textContent).toBe(\"Hello, Margaret!\");\n});
\n
\n

Busca de Dados

\n

Ao invés de realizar chamadas reais para uma API, você pode transformar a requisição em mock com dados fictícios. Transformando o dado em mock com dados “falsos” previne testes incompletos por causa de um backend indisponível, além de torná-los mais rápidos. Nota: Você ainda pode querer executar um subconjunto de testes usando um framework ”end-to-end” que valida se a aplicação inteira está funcionando em conjunto.

\n
// user.js\n\nimport React, { useState, useEffect } from \"react\";\n\nexport default function User(props) {\n  const [user, setUser] = useState(null);\n\n  async function fetchUserData(id) {\n    const response = await fetch(\"/\" + id);\n    setUser(await response.json());\n  }\n\n  useEffect(() => {\n    fetchUserData(props.id);\n  }, [props.id]);\n\n  if (!user) {\n    return \"loading...\";\n  }\n\n  return (\n    <details>\n      <summary>{user.name}</summary>\n      <strong>{user.age}</strong> years old\n      <br />\n      lives in {user.address}\n    </details>\n  );\n}
\n

Nós podemos escrever os testes para o componente:

\n
// user.test.js\n\nimport React from \"react\";\nimport { render, unmountComponentAtNode } from \"react-dom\";\nimport { act } from \"react-dom/test-utils\";\nimport User from \"./user\";\n\nlet container = null;\nbeforeEach(() => {\n  // configurar o elemento do DOM como o alvo da renderização\n  container = document.createElement(\"div\");\n  document.body.appendChild(container);\n});\n\nafterEach(() => {\n  // limpar na saída\n  unmountComponentAtNode(container);\n  container.remove();\n  container = null;\n});\n\nit(\"renders user data\", async () => {\n  const fakeUser = {    name: \"Joni Baez\",    age: \"32\",    address: \"123, Charming Avenue\"  };  jest.spyOn(global, \"fetch\").mockImplementation(() =>    Promise.resolve({      json: () => Promise.resolve(fakeUser)    })  );\n  // Usar a versão assíncrona de act para aplicar Promises resolvidas\n  await act(async () => {\n    render(<User id=\"123\" />, container);\n  });\n\n  expect(container.querySelector(\"summary\").textContent).toBe(fakeUser.name);\n  expect(container.querySelector(\"strong\").textContent).toBe(fakeUser.age);\n  expect(container.textContent).toContain(fakeUser.address);\n\n  // remover o mock para garantir que os testes estão completamente isolados  global.fetch.mockRestore();});
\n
\n

Transformando módulos em mock

\n

Alguns módulos podem não funcionar corretamente dentro de um ambiente de testes ou podem não ser essenciais para o teste em sí. Transformando eles em mock com dados fictícios pode facilitar a escrita dos testes para seu próprio código.

\n

Considere um componente Contact que possui um componente terceiro GoogleMap embutido:

\n
// map.js\n\nimport React from \"react\";\n\nimport { LoadScript, GoogleMap } from \"react-google-maps\";\nexport default function Map(props) {\n  return (\n    <LoadScript id=\"script-loader\" googleMapsApiKey=\"YOUR_API_KEY\">\n      <GoogleMap id=\"example-map\" center={props.center} />\n    </LoadScript>\n  );\n}\n\n// contact.js\n\nimport React from \"react\";\nimport Map from \"./map\";\n\nexport default function Contact(props) {\n  return (\n    <div>\n      <address>\n        Contact {props.name} via{\" \"}\n        <a data-testid=\"email\" href={\"mailto:\" + props.email}>\n          email\n        </a>\n        or on their <a data-testid=\"site\" href={props.site}>\n          website\n        </a>.\n      </address>\n      <Map center={props.center} />\n    </div>\n  );\n}
\n

Se nós não queremos carregar esse componente nos nossos testes, nós podemos transformar a dependência em mock de um componente fictício e executar o teste:

\n
// contact.test.js\n\nimport React from \"react\";\nimport { render, unmountComponentAtNode } from \"react-dom\";\nimport { act } from \"react-dom/test-utils\";\n\nimport Contact from \"./contact\";\nimport MockedMap from \"./map\";\n\njest.mock(\"./map\", () => {  return function DummyMap(props) {    return (      <div data-testid=\"map\">        {props.center.lat}:{props.center.long}      </div>    );  };});\nlet container = null;\nbeforeEach(() => {\n  // configurar o elemento do DOM como o alvo da renderização\n  container = document.createElement(\"div\");\n  document.body.appendChild(container);\n});\n\nafterEach(() => {\n  // limpar na saída\n  unmountComponentAtNode(container);\n  container.remove();\n  container = null;\n});\n\nit(\"should render contact information\", () => {\n  const center = { lat: 0, long: 0 };\n  act(() => {\n    render(\n      <Contact\n        name=\"Joni Baez\"\n        email=\"test@example.com\"\n        site=\"http://test.com\"\n        center={center}\n      />,\n      container\n    );\n  });\n\n  expect(\n    container.querySelector(\"[data-testid='email']\").getAttribute(\"href\")\n  ).toEqual(\"mailto:test@example.com\");\n\n  expect(\n    container.querySelector('[data-testid=\"site\"]').getAttribute(\"href\")\n  ).toEqual(\"http://test.com\");\n\n  expect(container.querySelector('[data-testid=\"map\"]').textContent).toEqual(\n    \"0:0\"\n  );\n});
\n
\n

Eventos

\n

Nós recomendamos despachar eventos reais de elementos do DOM e então afirmar no seu resultado. Considere um componente Toggle:

\n
// toggle.js\n\nimport React, { useState } from \"react\";\n\nexport default function Toggle(props) {\n  const [state, setState] = useState(false);\n  return (\n    <button\n      onClick={() => {\n        setState(previousState => !previousState);\n        props.onChange(!state);\n      }}\n      data-testid=\"toggle\"\n    >\n      {state === true ? \"Turn off\" : \"Turn on\"}\n    </button>\n  );\n}
\n

Poderíamos escrever testes para isso:

\n
// toggle.test.js\n\nimport React from \"react\";\nimport { render, unmountComponentAtNode } from \"react-dom\";\nimport { act } from \"react-dom/test-utils\";\n\nimport Toggle from \"./toggle\";\n\nlet container = null;\nbeforeEach(() => {\n  // configurar o elemento do DOM como o alvo da renderização\n  container = document.createElement(\"div\");\n  document.body.appendChild(container);});\nafterEach(() => {\n  // limpar na saída\n  unmountComponentAtNode(container);\n  container.remove();\n  container = null;\n});\n\nit(\"changes value when clicked\", () => {\n  const onChange = jest.fn();\n  act(() => {\n    render(<Toggle onChange={onChange} />, container);\n  });\n\n  // buscar pelo elemento do botão e disparar alguns eventos de click nele\n  const button = document.querySelector(\"[data-testid=toggle]\");\n  expect(button.innerHTML).toBe(\"Turn on\");\n\n  act(() => {\n    button.dispatchEvent(new MouseEvent(\"click\", { bubbles: true }));\n  });\n  expect(onChange).toHaveBeenCalledTimes(1);\n  expect(button.innerHTML).toBe(\"Turn off\");\n\n  act(() => {\n    for (let i = 0; i < 5; i++) {\n      button.dispatchEvent(new MouseEvent(\"click\", { bubbles: true }));\n    }  });\n\n  expect(onChange).toHaveBeenCalledTimes(6);\n  expect(button.innerHTML).toBe(\"Turn on\");\n});
\n

Os diferentes eventos do DOM e suas propriedades estão descritas em MDN. Note que você precisa passar { bubbles: true } em cada evento que for criado para que ele chegue ao React Listener pois o React delega os eventos ao root automaticamente.

\n
\n

Nota:

\n

React Testing Library oferece um auxiliar mais conciso para disparar eventos

\n
\n
\n

Temporizadores

\n

Seu código pode usar funções baseadas em tempo como setTimeout para programar mais trabalhos no futuro. Nesse exemplo abaixo, um painel de múltipla escolha espera por uma seleção e avança, esgotando o tempo se uma seleção não é feita em 5 segundos:

\n
// card.js\n\nimport React, { useEffect } from \"react\";\n\nexport default function Card(props) {\n  useEffect(() => {\n    const timeoutID = setTimeout(() => {\n      props.onSelect(null);\n    }, 5000);\n    return () => {\n      clearTimeout(timeoutID);\n    };\n  }, [props.onSelect]);\n\n  return [1, 2, 3, 4].map(choice => (\n    <button\n      key={choice}\n      data-testid={choice}\n      onClick={() => props.onSelect(choice)}\n    >\n      {choice}\n    </button>\n  ));\n}
\n

Nós podemos escrever testes para esse componente usando os mocks de temporizador do Jest e testando os diferentes estados que ele pode estar.

\n
// card.test.js\n\nimport React from \"react\";\nimport { render, unmountComponentAtNode } from \"react-dom\";\nimport { act } from \"react-dom/test-utils\";\n\nimport Card from \"./card\";\njest.useFakeTimers();\n\nlet container = null;\nbeforeEach(() => {\n  // configurar o elemento do DOM como o alvo da renderização\n  container = document.createElement(\"div\");\n  document.body.appendChild(container);\n});\n\nafterEach(() => {\n  // limpar na saída\n  unmountComponentAtNode(container);\n  container.remove();\n  container = null;\n});\n\nit(\"should select null after timing out\", () => {\n  const onSelect = jest.fn();\n  act(() => {\n    render(<Card onSelect={onSelect} />, container);\n  });\n\n  // move ahead in time by 100ms  act(() => {\n    jest.advanceTimersByTime(100);\n  });\n  expect(onSelect).not.toHaveBeenCalled();\n\n  // and then move ahead by 5 seconds  act(() => {\n    jest.advanceTimersByTime(5000);\n  });\n  expect(onSelect).toHaveBeenCalledWith(null);\n});\n\nit(\"should cleanup on being removed\", () => {\n  const onSelect = jest.fn();\n  act(() => {\n    render(<Card onSelect={onSelect} />, container);\n  });\n  act(() => {\n    jest.advanceTimersByTime(100);\n  });\n  expect(onSelect).not.toHaveBeenCalled();\n\n  // unmount the app\n  act(() => {\n    render(null, container);\n  });\n  act(() => {\n    jest.advanceTimersByTime(5000);\n  });\n  expect(onSelect).not.toHaveBeenCalled();\n});\n\nit(\"should accept selections\", () => {\n  const onSelect = jest.fn();\n  act(() => {\n    render(<Card onSelect={onSelect} />, container);\n  });\n\n  act(() => {\n    container\n      .querySelector(\"[data-testid='2']\")\n      .dispatchEvent(new MouseEvent(\"click\", { bubbles: true }));\n  });\n\n  expect(onSelect).toHaveBeenCalledWith(2);\n});
\n

Você pode usar os temporizadores fictícios apenas em alguns testes. Acima, nós habilitamos eles usando jest.useFakeTimers(). A principal vantagem que eles fornecem é que seus testes não precisam esperar os 5 segundos para executar e você também não precisa fazer o código ser mais convoluto apenas para o teste.

\n
\n

Testes de Snapshot

\n

Frameworks como o Jest também permitem você salvar “snapshots” de dados com toMatchSnapshot / toMatchInlineSnapshot. Com essas funções, nós podemos “salvar” o resultado do componente renderizado e garantir que uma mudança nele precisa ser explicitamente apontada como uma mudança no snapshot.

\n

Nesse exemplo, nós renderizamos um componente e formatamos o HTML renderizado com o pacote pretty, antes de salvá-lo como um inline snapshot.

\n
// hello.test.js, again\n\nimport React from \"react\";\nimport { render, unmountComponentAtNode } from \"react-dom\";\nimport { act } from \"react-dom/test-utils\";\nimport pretty from \"pretty\";\n\nimport Hello from \"./hello\";\n\nlet container = null;\nbeforeEach(() => {\n  // configurar o elemento do DOM como o alvo da renderização\n  container = document.createElement(\"div\");\n  document.body.appendChild(container);\n});\n\nafterEach(() => {\n  // limpar na saída\n  unmountComponentAtNode(container);\n  container.remove();\n  container = null;\n});\n\nit(\"should render a greeting\", () => {\n  act(() => {\n    render(<Hello />, container);\n  });\n\n  expect(    pretty(container.innerHTML)  ).toMatchInlineSnapshot(); /* ... gets filled automatically by jest ... */\n  act(() => {\n    render(<Hello name=\"Jenny\" />, container);\n  });\n\n  expect(\n    pretty(container.innerHTML)\n  ).toMatchInlineSnapshot(); /* ... gets filled automatically by jest ... */\n\n  act(() => {\n    render(<Hello name=\"Margaret\" />, container);\n  });\n\n  expect(\n    pretty(container.innerHTML)\n  ).toMatchInlineSnapshot(); /* ... gets filled automatically by jest ... */\n});
\n

Tipicamente é melhor fazer afirmações mais específicas do que utilizar snapshots. Esse tipo de teste inclui detalhes de implementação e portanto podem facilmente quebrar. Seletivamente transformar alguns componentes filhos em mock pode reduzir o tamanho do snapshot e mantê-los legíveis para o review de código.

\n
\n

Renderizações múltiplas

\n

Em casos raros, você pode estar executando um teste em um componente que utiliza múltiplos renderizadores. Por exemplo, você pode estar executando testes de snapshot em um componente com react-test-renderer, que internamente usa ReactDOM.render dentro de um componente filho para renderizar algum conteúdo. Nesse cenário, você pode encapsular as atualizações com o respectivo act() dos seus renderizadores.

\n
import { act as domAct } from \"react-dom/test-utils\";\nimport { act as testAct, create } from \"react-test-renderer\";\n// ...\nlet root;\ndomAct(() => {\n  testAct(() => {\n    root = create(<App />);\n  });\n});\nexpect(root).toMatchSnapshot();
\n
\n

Algo faltando?

\n

Se algum cenário comum não estiver coberto, por favor nos avise na página de issues no repositório da documentação oficial do site.

","frontmatter":{"title":"Receitas de Teste","next":"testing-environments.html","prev":"testing.html"},"fields":{"path":"content/docs/testing-recipes.md","slug":"docs/testing-recipes.html"}}},"pageContext":{"slug":"docs/testing-recipes.html"}},"staticQueryHashes":[]}