DEV Community: Mikéias Oliveira

Pare de mockar o window.fetch

Mikéias Oliveira — Sun, 10 Oct 2021 10:16:16 +0000

Porque você não deve mockar fetch ou seu cliente de API em seus testes e o que fazer em vez disso.

O que há de errado com este teste?

// __tests__/checkout.js
import * as React from 'react'
import { render, screen } from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import { client } from '../../utils/api-client'

jest.mock('../../utils/api-client')

test('clicking "confirm" submits payment', async () => {
  const shoppingCart = buildShoppingCart()
  render(<Checkout shoppingCart={shoppingCart} />)

  client.mockResolvedValueOnce(() => ({success: true}))

  userEvent.click(screen.getByRole('button', {name: /confirm/i}))
  expect(client).toHaveBeenCalledWith('checkout', {data: shoppingCart})
  expect(client).toHaveBeenCalledTimes(1)
  expect(await screen.findByText(/success/i)).toBeInTheDocument()
})

Esta é uma pergunta um pouco capciosa. Sem conhecer a API e os requisitos reais, Checkout bem como o endpoint /checkout, você não pode realmente responder. Então, desculpe por isso. Mas, um problema com isso é porque você está mockando o client. Como você realmente sabe que o client está sendo usado corretamente neste caso? Claro, client pode ser testado de forma unitária para garantir que está chamando window.fetch corretamente, mas como você sabe que client não mudou recentemente sua API para aceitar um body em vez de data? Oh, você está usando TypeScript, então eliminou uma categoria de bugs. Boa! Mas definitivamente existem alguns bugs de lógica de negócios que podem surgir porque estamos mockando o client aqui. Claro, você pode confiar em seus testes E2E para lhe dar essa confiança, mas não seria melhor apenas chamar o client e ter essa confiança aqui neste nível inferior, onde você tem um ciclo de feedback mais rápido? Se não for muito mais difícil, então com certeza!

Mas não queremos realmente fazer requisições fetch, certo? Então, vamos mockar window.fetch:

// __tests__/checkout.js
import * as React from 'react'
import { render, screen } from '@testing-library/react'
import userEvent from '@testing-library/user-event'

beforeAll(() => jest.spyOn(window, 'fetch'))
// assuming jest's resetMocks is configured to "true" so
// we don't need to worry about cleanup
// this also assumes that you've loaded a fetch polyfill like `whatwg-fetch`

test('clicking "confirm" submits payment', async () => {
  const shoppingCart = buildShoppingCart()
  render(<Checkout shoppingCart={shoppingCart} />)

  window.fetch.mockResolvedValueOnce({
    ok: true,
    json: async () => ({success: true}),
  })

  userEvent.click(screen.getByRole('button', {name: /confirm/i}))

  expect(window.fetch).toHaveBeenCalledWith(
    '/checkout',
    expect.objectContaining({
      method: 'POST',
      body: JSON.stringify(shoppingCart),
    }),
  )
  expect(window.fetch).toHaveBeenCalledTimes(1)
  expect(await screen.findByText(/success/i)).toBeInTheDocument()
})

Isso lhe dará um pouco mais de confiança de que uma requisição está realmente sendo feita, mas outra coisa que falta neste teste é um assertion de que headers tem um Content-Type: application/json. Sem isso, como você pode ter certeza de que o servidor reconhecerá a solicitação que você está fazendo? Ah, e como você garante que as informações de autenticação também estão sendo passadas corretamente?

Eu ouvi você, "mas verificamos client em nossos testes de unidade, Kent. O que mais você quer de mim!? Não quero copiar/colar assertions em todos os lugares!" Eu definitivamente entendo você aí. Mas e se houvesse uma maneira de evitar todo o trabalho extra em assertions em todos os lugares, mas também obter essa confiança em todos os testes? Continue lendo.

Uma coisa que realmente me incomoda em mockar coisas como fetch é que você acaba reimplementando todo o seu back-end... em todos os seus testes. Frequentemente em vários testes. É super irritante, especialmente quando é como: "neste teste, nós apenas assumimos as respostas normais do back-end", mas você tem que mockar elas em todo lugar. Nesses casos, é apenas um impasse de configuração que se interpõe entre você e o que você está tentando testar.

O que inevitavelmente acontece é um destes cenários:

Nós simulamos o client (como em nosso primeiro teste) e confiamos em alguns testes E2E para nos dar um pouco de confiança de que pelo menos as partes mais importantes estão usando o client corretamente. Isso resulta na reimplementação de nosso back-end em qualquer lugar em que testamos coisas que se relacionam com o back-end. Frequentemente duplicando o trabalho.
Nós mockamos window.fetch (como em nosso segundo teste). Isso é um pouco melhor, mas sofre de alguns dos mesmos problemas que o nº 1.
Colocamos todas as nossas coisas em pequenas funções e testamos a unidade de forma isolada (o que não é realmente uma coisa ruim por si só) e não nos incomodamos em testá-las na integração (o que não é ótimo).

Em última análise, temos menos confiança, um loop de feedback mais lento, muitos códigos duplicados ou qualquer combinação deles.

Uma coisa que acabou funcionando muito bem para mim por um longo tempo foi mockar o fetch em uma função, que é basicamente uma reimplementação de todas as partes do meu back-end que testei. Fiz uma forma disso no PayPal e funcionou muito bem. Você pode pensar assim:

// add this to your setupFilesAfterEnv config in jest so it's imported for every test file
import * as users from './users'

async function mockFetch(url, config) {
  switch (url) {
    case '/login': {
      const user = await users.login(JSON.parse(config.body))
      return {
        ok: true,
        status: 200,
        json: async () => ({user}),
      }
    }

    case '/checkout': {
      const isAuthorized = user.authorize(config.headers.Authorization)
      if (!isAuthorized) {
        return Promise.reject({
          ok: false,
          status: 401,
          json: async () => ({message: 'Not authorized'}),
        })
      }
      const shoppingCart = JSON.parse(config.body)
      // do whatever other things you need to do with this shopping cart
      return {
        ok: true,
        status: 200,
        json: async () => ({success: true}),
      }
    }

    default: {
      throw new Error(`Unhandled request: ${url}`)
    }
  }
}

beforeAll(() => jest.spyOn(window, 'fetch'))
beforeEach(() => window.fetch.mockImplementation(mockFetch))

Agora meu teste pode ser assim:

// __tests__/checkout.js
import * as React from 'react'
import { render, screen } from '@testing-library/react'
import userEvent from '@testing-library/user-event'

test('clicking "confirm" submits payment', async () => {
  const shoppingCart = buildShoppingCart()
  render(<Checkout shoppingCart={shoppingCart} />)

  userEvent.click(screen.getByRole('button', {name: /confirm/i}))

  expect(await screen.findByText(/success/i)).toBeInTheDocument()
})

Meu teste de "caminho feliz" não precisa fazer nada de especial. Talvez eu adicionasse uma opção para um caso de falha, mas fiquei muito feliz com isso.

O que é ótimo sobre isso é que eu apenas aumento minha confiança e tenho ainda menos código de teste para escrever na maioria dos casos.

Então eu descobri msw

msw é a abreviação de "Mock Service Worker". Agora, os service workers não funcionam no Node, eles são um recurso do navegador. No entanto, msw suporta Node de qualquer maneira para fins de testes.

A ideia básica é esta: criar um servidor mock que intercepte todas as solicitações e trate-o como você faria se fosse um servidor real. Em minha própria implementação, isso significa que faço um "banco de dados" com arquivos json com "seeds" para o banco de dados ou "builders" usando algo como faker ou test-data-bot. Em seguida, crio handlers de servidor (semelhante à API do Express) e interajo com esse banco de dados fictício. Isso torna meus testes rápidos e fáceis de escrever (uma vez que você tenha tudo configurado).

Você pode ter usado algo parecido com nock para fazer esse tipo de coisa antes. Mas o legal do msw (e algo sobre o qual posso escrever mais tarde) é que você também pode usar exatamente os mesmos handlers de servidor no navegador durante o desenvolvimento. Isso tem alguns grandes benefícios:

Se o endpoint não estiver pronto.
Se o endpoint estiver quebrado.
Se sua conexão com a Internet for lenta ou inexistente.

Você deve ter ouvido falar do Mirage, que faz quase a mesma coisa. Porém (atualmente) o Mirage não usa um service worker no cliente e eu realmente gosto que a aba network funcione da mesma forma, quer eu tenha o msw instalado ou não. Saiba mais sobre suas diferenças.

Exemplo

Então, com essa introdução, aqui está como faríamos nosso exemplo acima com o msw por trás do nosso servidor mock:

// server-handlers.js
// this is put into here so I can share these same handlers between my tests
// as well as my development in the browser. Pretty sweet!
import { rest } from 'msw' // msw supports graphql too!
import * as users from './users'

const handlers = [
  rest.get('/login', async (req, res, ctx) => {
    const user = await users.login(JSON.parse(req.body))
    return res(ctx.json({user}))
  }),

  rest.post('/checkout', async (req, res, ctx) => {
    const user = await users.login(JSON.parse(req.body))
    const isAuthorized = user.authorize(req.headers.Authorization)
    if (!isAuthorized) {
      return res(ctx.status(401), ctx.json({message: 'Not authorized'}))
    }
    const shoppingCart = JSON.parse(req.body)
    // do whatever other things you need to do with this shopping cart
    return res(ctx.json({success: true}))
  }),

]

export {handlers}

// test/server.js
import { rest } from 'msw'
import { setupServer } from 'msw/node'
import { handlers } from './server-handlers'

const server = setupServer(...handlers)

export { server, rest }

// test/setup-env.js
// add this to your setupFilesAfterEnv config in jest so it's imported for every test file
import { server } from './server.js'

beforeAll(() => server.listen())
// if you need to add a handler after calling setupServer for some specific test
// this will remove that handler for the rest of them
// (which is important for test isolation):
afterEach(() => server.resetHandlers())
afterAll(() => server.close())

Agora meu teste pode ser assim:

// __tests__/checkout.js
import * as React from 'react'
import { render, screen } from '@testing-library/react'
import userEvent from '@testing-library/user-event'

test('clicking "confirm" submits payment', async () => {
  const shoppingCart = buildShoppingCart()
  render(<Checkout shoppingCart={shoppingCart} />)

  userEvent.click(screen.getByRole('button', {name: /confirm/i}))

  expect(await screen.findByText(/success/i)).toBeInTheDocument()
})

Estou mais feliz com esta solução do que mockar fetch porque:

Não preciso me preocupar com os detalhes de implementação das propriedades e headers das respostas.
Se eu errar na forma como chamo fetch, meu handler de servidor não será chamado e meu teste (corretamente) falhará, o que me salvaria de enviar códigos quebrados.
Posso reutilizar exatamente esses mesmos handlers de servidor em meu desenvolvimento!

`Colocation` e testes de erro/caso extremo

Uma preocupação razoável sobre essa abordagem é que você acaba colocando todos os seus handlers de servidor em um só lugar e, em seguida, os testes que dependem desses handlers acabam em arquivos totalmente diferentes, então você perde os benefícios da colocation.

Em primeiro lugar, eu diria que você deseja colocar apenas as coisas que são importantes e exclusivas para o seu teste. Você não gostaria de ter que duplicar toda a configuração em cada teste. Apenas as partes que são únicas. Portanto, o "caminho feliz" é normalmente melhor apenas incluir no arquivo de configuração, removido do próprio teste. Caso contrário, você terá muito ruído e será difícil isolar o que está realmente sendo testado.

Mas e quanto aos casos extremos e erros? Para eles, o MSW tem a capacidade de adicionar handlers de servidor adicionais no tempo de execução (dentro de um teste) e, em seguida, redefinir o servidor para os handlers originais (removendo efetivamente os handlers de tempo de execução) para preservar o isolamento do teste. Aqui está um exemplo:

// __tests__/checkout.js
import * as React from 'react'
import { server, rest } from 'test/server'
import { render, screen } from '@testing-library/react'
import userEvent from '@testing-library/user-event'

// happy path test, no special server stuff
test('clicking "confirm" submits payment', async () => {
  const shoppingCart = buildShoppingCart()
  render(<Checkout shoppingCart={shoppingCart} />)

  userEvent.click(screen.getByRole('button', {name: /confirm/i}))

  expect(await screen.findByText(/success/i)).toBeInTheDocument()
})
// edge/error case, special server stuff
// note that the afterEach(() => server.resetHandlers()) we have in our
// setup file will ensure that the special handler is removed for other tests

test('shows server error if the request fails', async () => {
  const testErrorMessage = 'THIS IS A TEST FAILURE'

  server.use(
    rest.post('/checkout', async (req, res, ctx) => {
      return res(ctx.status(500), ctx.json({message: testErrorMessage}))
    }),
  )

  const shoppingCart = buildShoppingCart()
  render(<Checkout shoppingCart={shoppingCart} />)

  userEvent.click(screen.getByRole('button', {name: /confirm/i}))

  expect(await screen.findByRole('alert')).toHaveTextContent(testErrorMessage)
})

Portanto, você pode ter colocation onde for necessário e abstração onde for sensato.

Conclusão

Definitivamente, há mais coisas para fazer com msw, mas vamos encerrar por agora. Se você quiser ver msw em ação, meu workshop de 4 partes "Build React Apps" (incluído no EpicReact.Dev) usa e você pode encontrar todo o material no GitHub.

Um aspecto muito legal desse modelo de teste é que, como você está muito longe dos detalhes de implementação, pode fazer refatorações significativas e seus testes podem lhe dar a confiança de que você não quebrou a experiência do usuário. É para isso que servem os testes!! Adoro quando isso acontece:

I completely changed how authentication works in my app the other day and only needed to make a small tweak to my test utils and all my tests (unit, integration, and E2E) passed, giving me confidence that my user experience was unaffected by the change. That's what tests are for! https://t.co/tG5wJ76dut
— Kent C. Dodds (@kentcdodds ) June 7, 2020

Boa sorte!

Tradução livre do artigo “Stop mocking fetch” originalmente escrito por Kent C. Dodds, publicado em 03 de Junho de 2020.

Testando Detalhes de Implementação

Mikéias Oliveira — Mon, 23 Aug 2021 14:34:28 +0000

Testar detalhes de implementação é uma fórmula para o desastre. Por quê? E o que isso significa?

Na época em que eu estava usando enzyme (como todo mundo na época), tive cuidado com certas APIs. Eu evitei completamente shallow rendering para nunca usar APIs como instance(), state() ou find('ComponentName'). E em revisões de código de pull requests de outras pessoas, expliquei repetidamente por que é importante evitar essas APIs. O motivo é que cada uma delas permite testar detalhes de implementação de seus componentes. Muitas vezes as pessoas me perguntam o que quero dizer com "detalhes de implementação". Quero dizer: é difícil testar do jeito que está! Por que temos que fazer todas essas regras para torná-lo mais difícil?

Por que testar os detalhes de implementação é uma má prática?

Há dois motivos distintos pelos quais é importante evitar detalhes de implementação. Testes que testam os detalhes de implementação:

Podem falhar ao refatorar o código da aplicação. Falsos negativos;
Podem não falhar quando você quebrar o código da aplicação. Falso-positivo.

Para ser claro, o teste é: "o software funciona". Se o teste for bem-sucedido, isso significa que o resultado do teste foi "positivo" (o software está funcionando). Caso contrário, isso significa que o teste retorna "negativo" (não encontrou o software funcionando). O termo "Falso" refere-se a quando o teste retornou com um resultado incorreto, significando que o software está realmente corrompido, mas o teste foi aprovado (falso positivo) ou o software está realmente funcionando, mas o teste falhou (falso negativo).

Vamos dar uma olhada em cada um deles, usando um simples componente Accordion como exemplo:

// accordion.js

import * as React from 'react'
import AccordionContents from './accordion-contents'

class Accordion extends React.Component {
  state = {openIndex: 0}
  setOpenIndex = openIndex => this.setState({openIndex})
  render() {
    const {openIndex} = this.state
    return (
      <div>
        {this.props.items.map((item, index) => (
          <>
            <button onClick={() => this.setOpenIndex(index)}>
              {item.title}
            </button>
            {index === openIndex ? (
              <AccordionContents>{item.contents}</AccordionContents>
            ) : null}
          </>
        ))}
      </div>
    )
  }
}

export default Accordion

Se você está se perguntando por que estou usando um componente antigo de classe e não um componente funcional moderno (com hooks) para esses exemplos, continue lendo, é uma revelação interessante (que alguns de vocês experimentaram com enzyme que você já deve estar esperando).

E aqui está um teste que testa os detalhes de implementação:

// __tests__/accordion.enzyme.js

import * as React from 'react'

// if you're wondering why not shallow,
// then please read https://kcd.im/shallow
import Enzyme, {mount} from 'enzyme'
import EnzymeAdapter from 'enzyme-adapter-react-16'
import Accordion from '../accordion'

// Setup enzyme's react adapter
Enzyme.configure({adapter: new EnzymeAdapter()})

test('setOpenIndex sets the open index state properly', () => {
  const wrapper = mount(<Accordion items={[]} />)
  expect(wrapper.state('openIndex')).toBe(0)
  wrapper.instance().setOpenIndex(1)
  expect(wrapper.state('openIndex')).toBe(1)
})

test('Accordion renders AccordionContents with the item contents', () => {
  const hats = {title: 'Favorite Hats', contents: 'Fedoras are classy'}
  const footware = {
    title: 'Favorite Footware',
    contents: 'Flipflops are the best',
  }
  const wrapper = mount(<Accordion items={[hats, footware]} />)
  expect(wrapper.find('AccordionContents').props().children).toBe(hats.contents)
})

Levante a mão se você viu (ou escreveu) testes como este em sua base de código (🙌). Ok, agora vamos dar uma olhada em como as coisas quebram com esses testes...

Falsos-Negativos ao refatorar

Um número surpreendente de pessoas acha testes desagradáveis, especialmente o teste de interface do usuário. Por que? Existem várias razões para isso, mas uma grande razão que ouço repetidamente é que as pessoas passam muito tempo cuidando dos testes. "Cada vez que faço uma alteração no código, os testes quebram!" Este é um verdadeiro obstáculo à produtividade! Vamos ver como nossos testes são vítimas desse problema frustrante.

Digamos que eu esteja refatorando este accordion para prepará-lo para permitir que vários itens de accordion sejam abertos ao mesmo tempo. Uma refatoração não muda o comportamento existente, apenas muda a implementação. Portanto, vamos mudar a implementação de uma forma que não mude o comportamento.

Digamos que estamos trabalhando para adicionar a capacidade de vários elementos de accordion serem abertos de uma vez, então estamos mudando nosso estado interno de openIndex para openIndexes:

class Accordion extends React.Component {
-  state = {openIndex: 0}
-  setOpenIndex = openIndex => this.setState({openIndex})
+  state = {openIndexes: [0]}
+  setOpenIndex = openIndex => this.setState({openIndexes: [openIndex]})
   render() {
-    const {openIndex} = this.state
+    const {openIndexes} = this.state
     return (
       <div>
         {this.props.items.map((item, index) => (
           <>
             <button onClick={() => this.setOpenIndex(index)}>
               {item.title}
             </button>
-            {index === openIndex ? (
+            {openIndexes.includes(index) ? (
               <AccordionContents>{item.contents}</AccordionContents>
             ) : null}
           </>
         ))}
       </div>
     )
   }
 }

Incrível, fazemos uma verificação rápida no aplicativo e tudo ainda está funcionando corretamente, então quando chegarmos a este componente mais tarde para permitir a abertura de vários accordions, será muito fácil! Em seguida, executamos os testes e 💥kaboom💥 eles quebram. Qual deles quebrou? setOpenIndex sets the open index state properly.

Qual é a mensagem de erro?

expect(received).toBe(expected)
Expected value to be (using ===):
  0
Received:
  undefined

Essa falha no teste está nos alertando sobre um problema real? Não! O componente ainda funciona bem.

Isso é o que chamamos de falso-negativo. Isso significa que tivemos uma falha no teste, mas foi por causa de um teste quebrado, não do código da aplicação. Sinceramente, não consigo pensar em uma situação de falha de teste mais irritante. Bem, vamos prosseguir e corrigir nosso teste:

test('setOpenIndex sets the open index state properly', () => {
    const wrapper = mount(<Accordion items={[]} />)
-   expect(wrapper.state('openIndex')).toEqual(0)
+   expect(wrapper.state('openIndexes')).toEqual([0])
    wrapper.instance().setOpenIndex(1)
-   expect(wrapper.state('openIndex')).toEqual(1)
+   expect(wrapper.state('openIndexes')).toEqual([1])
})

A lição: testar detalhes de implementação pode fornecer um falso negativo quando você refatorar seu código. Isso leva a testes frágeis e frustrantes que parecem falhar sempre que você olha o código.

Falso-positivo

Ok, agora digamos que seu colega de trabalho está trabalhando no Accordion e vê este código:

<button onClick={() => this.setOpenIndex(index)}>{item.title}</button>

Imediatamente, seus sentimentos de otimização prematura surgem e eles dizem: "Ei! As arrow functions inline no render são ruins para o desempenho, então vou corrigir isso! Acho que isso deve funcionar, vou mudá-lo bem rápido e executar os testes."

<button onClick={this.setOpenIndex}>{item.title}</button>

Legal. Execute os testes e... ✅✅ incrível! Eles aceitam o código sem verificá-lo no navegador porque os testes dão confiança, certo? Esse commit vai em um PR completamente não relacionado que muda milhares de linhas de código e é compreensivelmente perdido. O accordion quebra na produção e Nancy não consegue os ingressos para ver Wicked in Salt Lake. Nancy está chorando e sua equipe se sente horrível.

Então, o que deu errado? Não tínhamos um teste para verificar se o estado muda quando setOpenIndex é chamado e se o conteúdo do accordion é exibido de forma adequada!? Sim, você fez! Mas o problema é que não houve nenhum teste para verificar se o botão estava conectado a setOpenIndex corretamente.

Isso é chamado de falso-positivo. Significa que não tivemos uma falha no teste, mas deveríamos! Então, como nos precavemos para garantir que isso não aconteça novamente? Precisamos adicionar outro teste para verificar se ao clicar no botão o estado é atualizado corretamente. E então preciso adicionar um limite de 100% de cobertura de código para que não cometamos esse erro novamente. Ah, e eu deveria escrever uma dúzia ou mais de plugins ESLint para garantir que as pessoas não usem essas APIs que incentivam testar os detalhes de implementação!

...Mas não vou incomodar ... Ugh, estou tão cansado de todos esses falsos-positivos e negativos que quase prefiro não escrever testes. APAGUE TODOS OS TESTES!

Não seria bom se tivéssemos uma ferramenta que entregasse um Pit of Success mais amplo? Sim, seria! E adivinhe, nós temos essa ferramenta!

Testes sem detalhes de implementação

Portanto, poderíamos reescrever todos esses testes com enzyme, nos limitando a APIs que não contenham detalhes de implementação, mas, em vez disso, vou apenas usar a React Testing Library, o que tornará muito difícil incluir detalhes de implementação em meus testes. Vamos verificar isso agora!

// __tests__/accordion.rtl.js

import '@testing-library/jest-dom/extend-expect'
import * as React from 'react'
import {render, screen} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import Accordion from '../accordion'

test('can open accordion items to see the contents', () => {
  const hats = {title: 'Favorite Hats', contents: 'Fedoras are classy'}

  const footware = {
    title: 'Favorite Footware',
    contents: 'Flipflops are the best',
  }

  render(<Accordion items={[hats, footware]} />)
  expect(screen.getByText(hats.contents)).toBeInTheDocument()
  expect(screen.queryByText(footware.contents)).not.toBeInTheDocument()

  userEvent.click(screen.getByText(footware.title))

  expect(screen.getByText(footware.contents)).toBeInTheDocument()
  expect(screen.queryByText(hats.contents)).not.toBeInTheDocument()
})

Maravilha! Um único teste que verifica muito bem todo o comportamento. E este teste passa se o meu estado é chamado openIndex, openIndexes ou tacosAreTasty 🌮. Legal! Livre-se daquele falso-negativo! E se eu conectar meu manipulador de cliques incorretamente, este teste falhará. Legal, livre-se daquele falso-positivo também! E não precisei memorizar nenhuma lista de regras. Eu apenas uso a ferramenta a partir de sua semântica e recebo um teste que realmente pode me dar confiança de que meu accordion está funcionando como o usuário também deseja.

Então... Quais são os detalhes de implementação?

Esta é a definição mais simples que posso fazer:

Os detalhes de implementação são coisas que os usuários do seu código normalmente não usarão, verão ou mesmo saberão.

Portanto, a primeira pergunta que precisamos responder é: "Quem é o usuário deste código." Bem, o usuário final que estará interagindo com nosso componente no navegador é definitivamente um usuário. Eles estarão observando e interagindo com os botões e conteúdos renderizados. Mas também temos o desenvolvedor que renderizará o accordion com propriedades (no nosso caso, uma determinada lista de itens). Portanto, os componentes React normalmente têm dois usuários: usuários finais e desenvolvedores. Usuários finais e desenvolvedores são os dois "usuários" que nosso código precisa considerar.

Ótimo, então quais partes do nosso código cada um desses usuários usa, vê e conhece? O usuário final verá/interagirá com o que renderizamos no método render. O desenvolvedor verá/interagirá com as propriedades que ele passa para o componente. Portanto, nosso teste normalmente deve apenas ver/interagir com as propriedades que foram passadas e a saída renderizada.

Isso é precisamente o que o React Testing Library faz. Damos a ele nosso próprio elemento React do componente Accordion com nossas propriedades falsas, então interagimos com a saída renderizada, consultando a saída para o conteúdo que será exibido para o usuário (ou garantindo que não será exibido) e clicando nos botões que são renderizados.

Agora considere o teste com enzyme. Com enzyme, acessamos o state de openIndex. Isso não é algo com que nenhum de nossos usuários se preocupe diretamente. Eles não sabem como é chamado, não sabem se o índice aberto é armazenado como um único valor primitivo ou armazenado como um array e, francamente, eles não se importam. Eles também não sabem ou não se importam com o método setOpenIndex especificamente. E ainda, nosso teste conhece esses dois detalhes de implementação.

Isso é o que torna nosso teste em enzyme sujeito a falsos-negativos. Porque, ao fazer nosso teste usar o componente de maneira diferente dos usuários finais e desenvolvedores, criamos um terceiro usuário que nosso código de aplicativo precisa considerar: os testes! E, francamente, os testes são um usuário com o qual ninguém se importa. Não quero que o código da minha aplicação considere os testes. Que completa perda de tempo. Não quero testes escritos para seu próprio bem. Os testes automatizados devem verificar se o código da aplicação funciona para os usuários de produção.

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

Leia mais sobre isso em Evitar o usuário Teste.

Então, e os hooks

Bem, ao que parece, o enzyme ainda tem muitos problemas com hooks. Acontece que quando você está testando os detalhes de implementação, uma mudança na implementação tem um grande impacto em seus testes. Isso é uma grande chatice porque se você estiver migrando componentes de classe para componentes de função com hooks, então seus testes não podem ajudá-lo a saber que você não quebrou nada no processo.

React Testing Library, por outro lado, funciona de qualquer maneira. Verifique o link codesandbox no final para vê-lo em ação. Gosto de chamar testes que você escreve com o React Testing Library:

Livres de detalhes de implementação e fáceis de refatorar.

Conclusão

Então, como você evita testar os detalhes de implementação? Usar as ferramentas certas é um bom começo. Aqui está um processo de como saber o que testar. Seguir este processo ajuda você a ter a mentalidade certa ao testar e, naturalmente, evitará os detalhes de implementação:

Qual parte de sua base de código não testada seria realmente ruim se quebrasse? (O processo de checkout);
Tente restringir a uma unidade ou algumas unidades de código (ao clicar no botão "checkout", uma solicitação com os itens do carrinho é enviada para /checkout);
Olhe para esse código e considere quem são os "usuários" (o desenvolvedor processando o formulário de checkout, o usuário final clicando no botão);
Escreva uma lista de instruções para que o usuário teste manualmente esse código para se certificar de que não está corrompido. (renderize o formulário com alguns dados falsos no carrinho, clique no botão checkout, certifique-se de que a API mock/checkout foi chamada com os dados corretos, responda com uma resposta falsa bem-sucedida, certifique-se de que a mensagem de sucesso seja exibida);
Transforme essa lista de instruções em um teste automatizado.

Espero que seja útil para você! Se você realmente deseja levar seus testes para o próximo nível, eu definitivamente recomendo que você obtenha uma licença Pro para TestingJavaScript.com 🏆

Boa sorte!

PS: Se você gostaria de brincar com tudo isso, aqui está um codesandbox.

Tradução livre do artigo “Testing Implementation Details” originalmente escrito por Kent C. Dodds, publicado em 17 de Agosto de 2020.

Barrel Pattern: import de módulos de forma elegante em JavaScript

Mikéias Oliveira — Mon, 26 Oct 2020 19:53:16 +0000

Introdução

Barrels são formas de acumular exportações de vários módulos em um arquivo base. Em resumo, são arquivos que re-exportam partes selecionadas de seu módulo. É uma técnica usada por muitas aplicações, inclusive Angular, React e Vue.

Provavelmente você já se deparou com importações neste formato:

// Vue
import { defineComponent, reactive, computed } from 'vue';

// Angular
import { Router, Route, ActivatedRoute } from '@angular/router';

Como Angular e Vue utilizam monorepo, ou seja, temos uma separação da aplicação em packages com responsabilidades definidas, é conveniente que as partes importantes desses packages sejam agrupados e exportados em um arquivo base que arroga a tarefa de ser o ponto central de acesso as partes daquele módulo. Também vale ressaltar que esta abordagem não se restringe a monorepo.

Importação de Módulos

Com a massiva atualização que o JavaScript recebeu em 2015 (aka ES6), dentre as novas funcionalidades recebemos o ESModules: um sistema oficial de módulos para o JavaScript. Havia alternativas como CommonJS e RequireJS, mas agora temos o suporte a módulos nativamente. Se deseja entender um pouco mais a fundo sobre módulos, indico o capítulo do livro do Dr. Axel Rauschmayer: Impatient Programmers - Modules. Ressalva: também é possível utilizar Barrel Pattern com CommonJS, mas me restringirei a explicá-lo com módulos nativos.

O contexto

Agora imaginemos um contexto: se estamos trabalhando com um Design System que se utiliza da filosofia Atomic Design, logo mais chegaremos a uma situação semelhante em diversas partes da nossa aplicação:

// Navbar.vue

import Menu from './components/menu/Menu';
import MenuList from './components/menu/MenuList';
import MenuItem from './components/menu/MenuItem';
import MenuLink from './components/menu/MenuLink';
import Select from './components/select/Select';
import SelectList from './components/select/SelectList';
import SelectOption from './components/select/SelectOption';

Percebemos que estamos importando 4 componentes da pasta menu e 3 da pasta select, repetindo o caminho de diretórios e alterando apenas o nome do componente. Certamente, se pudéssemos melhorar o código acima por um mais elegante seria interessante. Vejamos um exemplo com Barrel:

// Navbar.vue

import {
  Menu,
  MenuList,
  MenuItem,
  MenuLink
} from './components/menu';

import {
  Select,
  SelectList,
  SelectOption
} from './components/select';

Agora temos uma sintaxe mais enxuta, não precisando repetir o nome do componente devido a desestruturação do objeto que o arquivo barrel de cada módulo exporta. Porém, ainda podemos melhorar.

Caso não tenha familiaridade com o conceito de desestruturação de objetos e arrays, indico como referência: JavaScript.info - Destructuring Assignment.

A abordagem

Como já vimos, é possível desestruturar um objeto exportado e extrair somente o que nos é necessário. Então, vamos entender como funciona um arquivo barrel (o arquivo que exporta a API pública do módulo).

Vejamos como o Angular exporta partes do package @angular/router:

Analise na íntegra e veja que existe um arquivo index.ts exportando partes de router. A escolha do nome do arquivo não é por acaso. No sistema de módulos, quando referenciamos uma pasta, é buscado inicialmente por um arquivo index.

Levando em conta, assim ficaria nossa pasta components em uma aplicação Vue:

components
├── menu
│   │── Menu.vue
│   │── MenuList.vue
│   │── MenuItem.vue
│   │── MenuLink.vue
│   └── index.js <-- arquivo barrel
├── select
│   │── Select.vue
│   │── SelectList.vue
│   │── SelectOption.vue
│   └── index.js <-- arquivo barrel

Agora exportamos os componentes que desejamos:

// components/menu/index.js

export { default as Menu } from './Menu.vue';
export { default as MenuList } from './MenuList.vue';
export { default as MenuItem } from './MenuItem.vue';
export { default as MenuLink } from './MenuLink.vue';

Pronto. Ao acessarmos components/menu, o arquivo barrel (index.js) será chamado e retornará um merge dos objetos com nossos componentes, e então poderemos usar a desestruturação para extrair o que realmente precisamos:

// Navbar.vue

import { Menu, MenuList } from './components/menu';

Melhorando a abordagem

A abordagem acima é bem interessante, porém é bom ficar atento para não exagerar no uso de barrels. Nós não queremos ter muitos arquivos, pois isso é contraproducente e geralmente leva a problemas de dependência circular que às vezes podem ser bem complicados de resolver.

O recomendado é que cada módulo tenha um arquivo barrel, delegando ao mesmo a responsabilidade de exportar as suas partes convenientes. Deve concentrar a API pública e ser responsável por encapsular o acesso de suas partes. Caso a localização de uma pasta interna seja alterada, aqueles que utilizam seu módulo não devem ser afetados.

Sabendo disso, podemos colocar um arquivo barrel na raiz da pasta components e exportar suas partes internas de forma concentrada:

components
├── index.js
├── menu
│   └── ...
├── select
│   └── ...

Agora podemos exportar de duas formas:

Individual, sendo assim, não é necessário um arquivo barrel em cada pasta interna referente a um componente (recomendado):

// components/index.js

export { default as Menu } from './menu/Menu.vue';
export { default as MenuList } from './menu/MenuList.vue';
export { default as MenuItem } from './menu/MenuItem.vue';
export { default as MenuLink } from './menu/MenuLink.vue';

export { default as Select } from './select/Select.vue';
export { default as SelectList } from './select/SelectList.vue';
export { default as SelectOption } from './select/SelectOption.vue';

Ou reaproveitando os arquivos barrels e re-exportando no arquivo barrel base do módulo:

// components/index.js

export * from './menu';
export * from './select';

No final das contas teremos o seguinte resultado:

// Navbar.vue

import { Menu, MenuList, Select, SelectList } from './components';

Conseguimos acessar todos os nossos componentes apenas referenciando a pasta components. Não precisamos saber quais componentes estão lá, nem lembrar das subpastas que exportam algo. Tudo o que está acessível para importar encontra-se no arquivo barrel base (API pública do módulo).

Dica: se você usa o VSCode, apertando Ctrl+Space dentro das chaves lhe é sugerido uma lista do que é possível importar:

A indecisão

É provável que você tenha se perguntado a diferença em utilizar export * from vs export {} from. A reposta que eu daria: depende do contexto. No exemplo do @angular/router as duas formas de exportação são usadas. Preferencialmente, opte por exportações descritivas, ou melhor dizendo, export explícito, assim podemos controlar melhor o que de fato queremos expor.

export * from adiciona um toque de "mágica". Controlar o que estamos exportando é um pouco mais difícil, já que precisaremos ir no arquivo que é re-exportado para ter uma melhor noção do que realmente está sendo exposto. Por outro lado, se você tem uma API muito bem definida, partes importantes do seu módulo que não são constantemente alteradas, é plausível utilizar esta forma "mágica".

Avalie o seu contexto e aplique como melhor planejar. Não é uma regra. Não terceirize suas decisões.

Conclusão

Entendemos uma abordagem para reduzir as repetições em importações, melhorar o compartilhamento de código entre módulos especializados, encapsular caminhos de arquivos e reduzir quebra de dependências, e também uma forma mais elegante de manter nosso código.

Portanto, use este pattern com cautela. Há contextos em que ele é muito útil. O problema não está no Barrel Pattern, e sim no mau uso do mesmo.

Referências

Soli Deo Gloria

DEV Community: Mikéias Oliveira

Pare de mockar o window.fetch

O que há de errado com este teste?

O que inevitavelmente acontece é um destes cenários:

Então eu descobri msw

Exemplo

Colocation e testes de erro/caso extremo

Conclusão

Testando Detalhes de Implementação

Por que testar os detalhes de implementação é uma má prática?

Falsos-Negativos ao refatorar

Falso-positivo

Testes sem detalhes de implementação

Então... Quais são os detalhes de implementação?

Então, e os hooks

Conclusão

Barrel Pattern: import de módulos de forma elegante em JavaScript

Introdução

Importação de Módulos

O contexto

A abordagem

Melhorando a abordagem

A indecisão

Conclusão

Referências

`Colocation` e testes de erro/caso extremo