Quando decidimos escrever testes para nossos componentes no frontend, é uma boa prática, e até uma forma de facilitar nossa escrita de testes, separar o que é lógica do que é apresentação. Dessa forma, podemos ter testes separados para cada uma das responsabilidades.
Porém, em alguns casos, um componente não é apenas responsável pela apresentação dos dados, mas também pela busca desses dados.
A partir da versão 13 do Next.js, com o uso do diretório app
, todos os componentes criados são server components
, o que significa que a renderização ocorre do lado do servidor. Isso abre várias possibilidades, como por exemplo, fazer chamadas de API assíncronas na definição do componente, aguardar a resposta e utilizar os dados dessa resposta na renderização do componente.
Como exemplo, podemos definir nosso componente como uma função assíncrona:
async function MyAsyncComponent() {
const data = await fetchData();
return <div data-testid="painted-content">{data}</div>;
}
Em um componente marcado como async
, podemos utilizar o await
para aguardar. Não precisamos, nem devemos, utilizar hooks como useState
ou useEffect
.
Escrevendo o nosso teste da seguinte forma, com a sintaxe familiar da React Testing Library, ele falhará:
describe('Test My Async Component', () => {
it('should render the component', () => {
render(<MyAsyncComponent />)
const sut = screen.getByTestId('painted-content')
expect(sut.textContent).toBe('async content')
})
})
O erro retornado é algo como Objects are not valid as a React child (found: [object Promise]). If you meant to render a collection of children, use an array instead.
, ou seja, o componente não está retornando um elemento JSX para ser renderizado.
Como resolver esse problema?
Partindo do princípio de que um componente nada mais é do que uma função assíncrona que recebe parâmetros para renderizar seu conteúdo, podemos escrever nosso teste da seguinte forma:
describe('Test My Async Component', () => {
it('should render the component', async () => {
const jsx = await MyAsyncComponent()
render(jsx)
const sut = screen.getByTestId('painted-content')
expect(sut.textContent).toBe('async content')
})
})
O que fizemos no exemplo acima foi transformar nosso teste anterior em um teste assíncrono, aguardando a função do componente resolver, armazenando seu JSX em uma constante, e passando essa constante com JSX para o método render
. Ao inspecionar o tipo do retorno do nosso componente, temos o tipo JSX.Element
, exatamente o mesmo tipo de dado que a função render
aceita. Dessa forma, o teste agora roda e passa com sucesso.
Refatorando
É bem provável que você vá renderizar o componente em diversos casos de testes. Para isso, podemos abstrair para uma função própria:
async function renderComponent() {
const jsx = await MyAsyncComponent()
return render(jsx)
}
describe('Test My Async Component', () => {
it('should render the component', async () => {
await renderComponent()
const sut = screen.getByTestId('painted-content')
expect(sut.textContent).toBe('async content')
})
})
Dessa forma, evitamos reescrever em todos os casos de teste a chamada assíncrona do nosso componente e a renderização do JSX. Porém, podemos ir além. Em uma aplicação real, é comum termos diversos componentes assíncronos que precisam ser testados. Inclusive, alguns deles, diferente dos nossos exemplos até aqui, podem receber props
. Para isso, podemos utilizar os genéricos do TypeScript para facilitar ainda mais a renderização:
async function renderAsync<T>(
asyncComponent: (props: T) => Promise<JSX.Element>,
props: T = {} as T
) {
const jsx = await asyncComponent(props);
render(jsx);
}
Utilização:
describe('Test My Async Component', () => {
it('should render the component without params', async () => {
await renderAsync(MyAsyncComponent)
const sut = screen.getByTestId('painted-content')
expect(sut.textContent).toBe('async content')
})
})
describe('Test My Async Component with props', () => {
it('should render the component with params', async () => {
const props = { params: 'with my example param' }
await renderAsync(MyAsyncComponentWithProps, props)
const sut = screen.getByTestId('painted-content')
expect(sut.textContent).toBe('async content with my example param')
})
})
Conclusão
Ao escrever testes para componentes assíncronos no frontend, é essencial compreender a diferença entre componentes de apresentação e componentes que também lidam com a lógica de busca de dados. Com a introdução dos server components
no Next.js 13, novas oportunidades surgem para otimizar a renderização no servidor e simplificar o manuseio de dados assíncronos.
Ao transformar nossos testes em assíncronos e refatorar a lógica de renderização, conseguimos garantir que nossos componentes sejam testados de forma eficaz e eficiente. Além disso, utilizando genéricos do TypeScript, podemos criar funções de renderização reutilizáveis que tornam nossos testes mais limpos e mantêm nosso código mais organizado.
Com essas práticas, podemos melhorar a confiabilidade e a mantenibilidade dos testes em nossos projetos de frontend, garantindo que nossos componentes funcionem conforme esperado em diferentes cenários.
Referências
publicado também em: https://christiantld.vercel.app
Top comments (0)