@pablordinella
@pablordinella
Pega o retorno do seu componente e te dá utilitários para:
@testing-library/dom
@testing-library/react
@testing-library/dom
queries
fireEvent
async utils
@testing-library/dom
queries
ByLabelText
ByPlaceholderText
ByText
ByAltText
ByTitle
ByDisplayValue
ByRole
ByTestId
get
getAll
query
queryAll
find
findAll
X
fireEvent
click
change
input
keyDown
keyUp
blur
focus
...
wait
waitForElement
waitForDomChange
waitForElementToBeRemoved
async utils
@testing-library/dom
@testing-library/react a.k.a. react-testing-library
render()
Tudo isso são coisas que o usuário final não pode fazer, entao seu teste também não deveria fazer
É repleto de detalhes de implementação (nome de componentes e props). Qualquer refactor quebra o teste
É repleto de detalhes de implementação (nome de componentes e props). Qualquer refactor quebra o teste
Muitas vezes é difícil entender a falha
É repleto de detalhes de implementação (nome de componentes e props). Qualquer refactor quebra o teste
Muitas vezes é difícil entender a falha
O dev se torna descuidado e atualiza o snapshot por atualizar
É repleto de detalhes de implementação (nome de componentes e props). Qualquer refactor quebra o teste
Muitas vezes é difícil entender a falha
Como o teste quebra a todo momento, o dev se torna descuidado e atualiza o snapshot por atualizar
Causa falsa sensação de que o teste está cobrindo o cenário, e acabamos por não escrever o teste adequado
A intenção do teste fica clara; testa somente o que importa
Baseia-se na renderização real do componente, o resultado no DOM
Baseia-se na implementação
Não garante que o conteúdo do tab certo está aparecendo (falso positivo)
Só se importa com o que está no DOM
Valida o que o usuário está vendo
Resiliente, não quebra com refatorações
Nomes de classes CSS
State/Props
Nomes de componentes
Qualquer coisa que o usuário final não vê!
ByLabelText
ByPlaceholderText
ByText
ByAltText
ByTitle
ByDisplayValue
ByRole
ByTestId
.find('Progress')
wait
waitForElement
waitForDomChange
waitForElementToBeRemoved
Mudança de mindset
Quase todas as vezes a dificuldade estava no conhecimento da API do DOM
Pensar em como o usuário encontra os elementos e interage com eles
Experimentação com o devtools e consultas no MDN
Simulação de eventos do usuário
click(element)
dblClick(element)
type(element, text, [options])
selectOptions(element, values)
fireEvent.change(input, { target: { value: '23' } })
userEvent.type(input, '23')
Adicione o @testing-library/react
Comece a testar novos componentes com ele
Refatore testes que forem quebrando
caro
casos complexos
lento
barato
casos simples
rápido
@pablordinella