Aula 66
Verificando se o componente “select” recebe props corretamente
Summary
Resumo da Implementação de Testes
Neste vídeo, o foco é a implementação de testes para um componente de seleção (select
). O objetivo principal é verificar se as propriedades (props) do componente estão definidas corretamente.
Estrutura dos Testes
-
Configuração Inicial:
- Utiliza-se
shallow
doenzyme
para montar o componente e criar um wrapper. - Um bloco
beforeEach
é criado para garantir que o componente seja inicializado antes de cada teste, prevenindo efeitos colaterais.
- Utiliza-se
-
Definição da Variável Component:
- A variável que representa o componente é definida como
let
para permitir redefinições antes de cada teste, ao invés deconst
.
- A variável que representa o componente é definida como
-
Verificando Props:
- O primeiro teste verifica se a prop
name
é corretamente configurada como "país". - Utiliza-se
component.find(select).prop(name)
para verificar o valor esperado.
- O primeiro teste verifica se a prop
-
Alternativas na Definição de Props:
- O autor menciona que é possível alterar a maneira de definir props usando
wrapper.setProps()
para facilitar a identificação de mudanças.
- O autor menciona que é possível alterar a maneira de definir props usando
-
Testando o
onChange
:- O teste para a prop
onChange
propõe o uso de uma função mock (ou stub) para verificar a passagem correta da função. - Um teste é feito para garantir que o
onChange
passado é o mesmo que o esperado, verificando referências de função.
- O teste para a prop
Conclusão
A aula enfatiza a importância de escrever testes de forma clara e explícita. O autor convida os espectadores a deixarem comentários sobre as melhores práticas na escrita de testes unitários. A próxima aula promete continuar a exploração do tema de testes.
Agradecimentos: Obrigado por assistir e até a próxima aula!
Video Transcript
Estamos aqui de volta, vamos continuar a implementação dos testes.
O próximo teste é verificar se as próprias que esse componente select aqui recebe foram definidas
corretamente. Então, para poder fazer isso é aquele mesmo processo. Você vai usar o shallow
para poder montar o componente e criar aquele enzyme wrapper para poder finalmente usar o find
e outros métodos para poder verificar o valor das próprias, essas coisas.
Agora você pode fazer o mesmo código anteriormente ou você pode reutilizar esse código.
Então, mesmo maneira que a gente já fez anteriormente, vamos criar aquele bloco de
before it e vamos trair essa variável prop componente para poder ser disponível para cada teste.
Então, vamos lá, vamos criar aquele before it.
Então, esse before it roda sempre antes de cada teste, antes de cada before it.
Então, a gente já viu isso anteriormente, então vamos aqui rapidinho fazer isso.
Vamos ver esses caras para o bloco de before it para que a gente definir essas próprias
fácil e usar o shallow para poder criar um enzyme wrapper antes de cada teste para criar tudo novamente do zero.
Para não ter nenhum efeito colateral de outro teste.
Então, agora o prop component não são mais acessíveis aqui dentro desse teste.
Então, para poder esse cara acessar essa variável component, a gente vai ter que definir esse cara num bloco acima.
Então, em vez de ser const, eu vou botar esse cara como let component num bloco acima.
A gente usa let porque a variável component vai ser redefinida mais de uma vez,
vai ser redefinida antes de cada teste, então a gente não pode usar o const aqui.
Outra coisa a gente pode fazer também é poder deixar o...
pegar esse props e deixar disponível a outros testes, mas vamos deixar aqui por enquanto, certo?
Então, vamos lá, o component agora está acessível.
Vamos verificar essa props, definir isso corretamente para o select.
Então, vamos ver aqui.
Né, vale, não tem chance de ser ok.
Então, vamos fazer aqui...
essa prop aqui...
vamos fazer de uma maneira...
vamos ver aqui.
Primeiramente, vamos dar o component find do select.
Aí você vai verificar prop name.
Para essa primeira aqui, vamos fazer essa primeira.
Component find select prop name, expect esse cara que seja o quê?
Nesse caso aqui, a gente montou o componente com essas props aqui com o name país.
País, né? País, eu botei país.
País, mas...
Nesse caso, a gente espera que seja país, né?
Vamos lá verificar o teste no terminal que está passando.
Se a gente mudar isso aqui e botar o nome errado ali para o name, ele mostra que está errado.
Certo? Então, está tudo correto.
Então, da maneira que eu fiz aqui, eu não usei o props.name.
Então, depende de você como você quiser fazer isso aqui.
Se você quiser usar o props.name lá,
você tem que pegar o props e botar como let.
Dessa maneira aqui.
Certo? A gente já fez isso antes.
Mas, às vezes, para o negócio de testes,
quando você está testando as coisas, às vezes não é bom você fazer esse negócio
e incluir lógica nos testes, essas coisas, é melhor ter o valor explícito.
Então, só dando essa...
Só esse alarm para você, certo?
Então, depende de você para ver se o teste está realmente...
Da maneira que você quer. Tem outra maneira de definir esse teste aqui.
Também é...
Você pode definir seus props aqui novamente.
Por exemplo, component, set props.
Name.
Sei lá, outra coisa que...
Uma coisa que a gente pode escolher, vamos ver...
Bruta, sei lá.
Aí, nesse caso, quando a gente chama o wrapper.set props,
ele vai mudar essa props.name para fruta.
Em vez de ser o país aqui, que a gente definiu inicialmente, vai ser fruta.
Aí, você pega e expect component.select.prop.name
to be okay, to be fruta.
Vamos ver o terminal, tudo ok.
Vamos fazer com esse teste falhar para ver se realmente está funcionando.
Você vê que espera que o valor seja fruto, mas receber fruta 2.
Então, esse cara está funcionando.
Então, esse aqui pode ser uma maneira melhor de escrever esses testes.
Em vez de a gente já tinha inscrito de outra maneira,
se essa é outra maneira de escrever, essa aqui talvez seja melhor
porque está mais claro qual é o que você mudou a prop.
E quando você mudou a prop, o component realmente pegou
e viu que prop.name é realmente fruta.
Em vez de usar o props.name que uma gente já fez antes em outros testes.
Então, que é outra maneira, essa talvez seja melhor.
Se você concordar ou não concordar, por favor, deixe comentários aí.
Diga aí qual é a melhor maneira de escrever esses testes unitários.
Por isso é só por esse teste aqui para o name.
Agora vamos ver o value aqui.
Se a gente ver aqui, pode fazer outro teste também para cada prop.
Depende de você.
Então, eu vou deixar o negócio aqui fazendo o mesmo teste
só para a gente ir mais rápido aqui.
Então, eu fiz o teste para o name, deixa eu quebrar a linha aqui.
Mas eu também quero mudar o valor do cara aqui.
Vamos falar o value para en em glaterra.
Aí a gente espera que o componente findSelectPropValue agora que seja o quê?
Que seja en en para en glaterra.
Vamos salvar e ver se deu problema, tudo ok.
Vamos fazer o cara falhar.
Então vai lá, o que você vai fazer para o teste falar aqui na implementação?
Sei lá, por acidente a gente inscrito um dois ali.
Então realmente, valeu, então está correto.
Agora, finalmente vamos testar o onChange.
Então, para o onChange você pode fazer aqui o quê?
OnChange é só ter que ser uma função.
Na verdade, esse cara aqui nem se importa, ele só se importa que você passe ele.
Qualquer valor seja definido no onChange aqui.
Mas esse valor tem que vir das props.
Então, a gente vai definir essa prop, um change para ser qualquer coisa.
Para ser uma função e retornando, por exemplo, ou jas.fn ou qualquer coisa, certo?
Então, vou deixar esse cara assim.
Aí a gente vai verificar.
O problema é que a gente não dá para saber se esse cara realmente é o cara que foi incluído.
Porque quando a gente faz o findSelectProp, onChange, toBe o quê?
A gente não sabe o que vai ser.
A gente não pode escrever toBe função assim.
Não é a mesma função que essa função.
Então, talvez você tenha que fazer assim.
Faz uma variável assim.
Aí define a função.
OnChangeMock, sei lá.
Aí você faz o stub, sei lá o que você chama esse cara.
Vou deixar a mock.
OnChangeMock.
Aí esse cara aqui você passa como prop.
Aí você espera que o onChange aqui também seja o onChangeMock aqui desse cara.
Então, você espera que esse caso seja onChangeMock.
Aqui para você ver melhor.
Certo?
Vamos só ver que não deu problema.
Sem problemas, vamos mudar aqui o onChange.
Vamos mudar a função que retorna no.
É a mesma definição desse aqui, mas não vai ser a mesma função.
Você note que expected value to be esse cara, mas recebeu outra coisa.
Outra função.
Então, essa função, embora que a implementação seja a mesma do onChangeMock,
não são as mesmas funções.
As referências são diferentes.
Então, a gente espera nesse teste que as referências sejam as mesmas,
porque a gente só pega o valor que foi passado como o próprio
e passa de novo para o próprio onChangeDoSelect.
Vamos salvar aí.
Tudo ok agora.
As testes estão passando novamente.
Então, essa é uma maneira de testar as props de um componente de maneira mais clara,
de maneira mais explícita, para você ver realmente
você seta os condições aqui e as expectativas.
Certo?
Muito obrigado por assistir e até a próxima aula,
onde a gente vai continuar com os testes.
Até lá.
Tchau.
Nenhum comentário ainda (loading...)
Nenhum comentário ainda (loading...)
Gostou da aula? 😆👍
Apoie nosso trabalho com uma doação: