Comecei com o TDD há dois meses, e me sinto envergonhado de não tem começado bem antes hahahaha No começo foi bem estranho, tipo "como assim eu escrevo o teste sem ter a funcionalidade? NÃO FAZ SENTIDO", mas depois "Puts, ainda bem que rodei o teste, esqueci daquela regra de negócio" hahaha. Excelente vídeo! Like
Muito bom meu caro! falo muito essa questão de pensar nos testes antes pro meu pessoal, e também na equipe q lidero. Bom ver mais pessoas levantando a bandeira de bons testes. um abraço
Escrever software sem teste! Que más lembranças você me trouxe :D Ao longo da minha carreira, consegui entender que isso tá muito relacionado em primeiro lugar à cultura da empresa, em segundo lugar, ao interesse do desenvolvedor. Infelizmente ainda existem devs que falam que escrever teste é perda de tempo (ter retrabalho porque o sistema quebrou em produção ou perder noites em claro porque aquele bug voltou, aparentente não conta como perda de tempo). Sobre testar, o que eles não sabem é que, talvez, isso fosse lhes garantir boas noites de sono e um salário mais gordinho. Qualidade tem preço.
Eai Erick blz!? Cara primeiramente parabéns pelo conteúdo e pela carreira top que vc criou, vindo de São Matheus (próximo da minha cidade) e indo para o mundo! Comecei ontem seu curso de serveless e estou achando incrível, entendi muitos conceitos que tinha dúvidas em apenas um dia! Cara eu gostaria muito que vc fizesse um vídeo comentando sobre como montar um portifólio top para apresentar nas empresas. Eu tenho muito problema em como expor meus projetos criados de uma maneira interessante para as empresas ou para o público em geral!! Vlw pelos vídeos!!
Olá, Erick! Curti muito seu vídeo. Você teria algum link, vídeo ou livro para indicar, com exemplos mais práticos para quem tá começando e quer aprender mais sobre como testar? Obrigado por compartilhar sua experiência, abraço!
jah deixei o like como sempre..peguei um sistema legado em que não há nada de testes c tecnologia antiga tb (ejb 2, sencha.js, struts, java 1.5, ant (nem maven eh rs)..entao, ainda n colocamos testes nesse sistema atual.. qto aos tipos de video, os de video aula tecnicos sao otimos.. esse de hj poderia ser complementado c um de video-aula tecnico. parabens..vlw
Nao acho mt polemico nao.. Tira onda quem faz tdd. Eu vou fazendo tanta coisa uma atras da outra, que nem o card do jira ou a anotacao do confluence eu crio
Nice Erick, perfeito seu posicionamento. Já fiz parte de times que não tinham a cultura de code-review inclusa no dia a dia, quanto mais de testes... A cada nova feature, testavam manualmente e o resultado era bugs em produção a cada fim de sprint. Quando fui alocado no time e percebi o tamanho do problema, tentei conversar e me propus a ajudar, mas o líder era cabeçudo e não queria saber de testes usando como argumento exatamente o que você no vídeo, a pressão por entrega do time de negócios. O que você tem a dizer quando se tem pouca voz no time pra sugerir novas culturas e boas práticas? É válido chegar e escrever os testes sozinho, levando em conta que no fluxo de deploy não tem uma etapa de testes e considerando também que o time não vai manter o teste que você escrever? Você acha que é possível gradualmente ir mudando a cabeça do time e fazê-lo se adaptar a você, ou você se adapta e eles e entrega tudo sem teste?
discordo, qualidade é responsabilidade de dev, QA é necessário a depender da complexidade, para fazer auxiliar o time com testes mais complexos, principalmente ligados a requisitos não funcionais.
Como sempre, excelente abordagem! O que tu acha do "Consumer-Driven Contract" ? Quando conheci com mais detalhes e exemplos, percebi que é uma abordagem de testes mais próxima do usuário, onde tu gera um "contrato" dizendo que para o caso de uso onde seus inputs é X Y e Z, tem que ter F como retorno, do contrário o teste quebrou. Existem libs que facilitam essa implementação como Pact.js (github.com/pact-foundation/pact-js). Mas entendendo esse contexto, isso acaba sendo aplicável pra praticamente qualquer funcão ser testável, mesmo que derrepente fazendo "na mão". Dito isso, acho que parte do problema é esse posicionamento como desenvolvedor que tu disse (e concordo), e outra parte é de quão próximo do negócio o time esta, o quão integrado as regras o desenvolvedor esta. Do contrário, fica muito difícil ele definir cenários de testes sem conhecer muito o produto. E por último, essa ideia de querer começar testes em tudo, sempre na minha opinião assusta os desenvolvedores. Tem que começar injetar endorfina aos poucos, pro seu organismo se viciar naquilo, e quando tu ver, já esta aplicando testes em tudo. É um processo....
Não entendi a pergunta Victor. Docker é o ambiente que você executa sua aplicação, TDD é como você cria funções de automação para validar seu código. Acho que Docker e TDD não tenham relação
"Faz funcionar, depois a gente faz direito." Isso NUNCA acontece, e não é só em programação não! Quando eu era network manager era a mesma coisa: "sobe esse switch de qualquer jeito só pra subir a rede, depois a gente configura direito." "Importante é construir essa rede e colocar cliente na base, depois a gente faz documentação."
Eu dei altas risadas aqui, porque é quase sempre assim: faz e bota em produção. Depois tá todo mundo tomando no c* tendo retrabalho e fazendo hora extra. Eu estou na ponta do QA e não viam muito valor. Daí um dia resolveram envolver o time de QA em um projeto novo. Em pouco alguns minutos quebramos o sistema. Depois de um tempo ouvimos a seguinte pergunta: por que não envolvemos o time de QA antes?
Então a empresa chega com 1 prazo fora da realidade, trabalhamos 30 dias sem parar 12h por dia ou até mais, e se não tem teste a culpa é do dev? kkkkkk bulshitagem pura desculpa
Comecei com o TDD há dois meses, e me sinto envergonhado de não tem começado bem antes hahahaha
No começo foi bem estranho, tipo "como assim eu escrevo o teste sem ter a funcionalidade? NÃO FAZ SENTIDO", mas depois "Puts, ainda bem que rodei o teste, esqueci daquela regra de negócio" hahaha.
Excelente vídeo! Like
Erick, gostaria de um vídeo sobre estratégias de autenticação(JWT, OAuth etc). AH, e um solinho nessa CortX ai....
Muito bom meu caro! falo muito essa questão de pensar nos testes antes pro meu pessoal, e também na equipe q lidero. Bom ver mais pessoas levantando a bandeira de bons testes. um abraço
Escrever software sem teste! Que más lembranças você me trouxe :D Ao longo da minha carreira, consegui entender que isso tá muito relacionado em primeiro lugar à cultura da empresa, em segundo lugar, ao interesse do desenvolvedor. Infelizmente ainda existem devs que falam que escrever teste é perda de tempo (ter retrabalho porque o sistema quebrou em produção ou perder noites em claro porque aquele bug voltou, aparentente não conta como perda de tempo). Sobre testar, o que eles não sabem é que, talvez, isso fosse lhes garantir boas noites de sono e um salário mais gordinho. Qualidade tem preço.
Eai Erick blz!? Cara primeiramente parabéns pelo conteúdo e pela carreira top que vc criou, vindo de São Matheus (próximo da minha cidade) e indo para o mundo! Comecei ontem seu curso de serveless e estou achando incrível, entendi muitos conceitos que tinha dúvidas em apenas um dia! Cara eu gostaria muito que vc fizesse um vídeo comentando sobre como montar um portifólio top para apresentar nas empresas. Eu tenho muito problema em como expor meus projetos criados de uma maneira interessante para as empresas ou para o público em geral!! Vlw pelos vídeos!!
Ótimo conteúdo, Erick!
Minha sugestão é um vídeo falando sobre mitos e verdades de aplicações em node :)
Muito show o vídeo, brigadão pelo trabalho! Seria muito bom continuar com conteúdo técnico, tem me ajudado bastante.
Ótimo Matheus!! Fico feliz que tenha gostado!
Muito massa, estou iniciando nos testes. De fato, já me encontrei nessa situação de correria muitas vezes, inclusive nesse caso de re-escrever depois.
Massa mano, na empresa que estou o líder implementou TDD e mano, isso é vida!
Gostei do relato da experiência, estou sofrendo as consequências de um projeto que já utilizou muito a "metodologia" descrita.
ahahhaa complicado né? Já passei muito por isso
Mto legal! Parabéns pelo conteúdo.
Olá, Erick! Curti muito seu vídeo. Você teria algum link, vídeo ou livro para indicar, com exemplos mais práticos para quem tá começando e quer aprender mais sobre como testar? Obrigado por compartilhar sua experiência, abraço!
Rapaz, não tenho nenhum em específico.
Ótimo conteúdo. Quais as melhores ferramentas de cobertura de testes?
jah deixei o like como sempre..peguei um sistema legado em que não há nada de testes c tecnologia antiga tb (ejb 2, sencha.js, struts, java 1.5, ant (nem maven eh rs)..entao, ainda n colocamos testes nesse sistema atual..
qto aos tipos de video, os de video aula tecnicos sao otimos..
esse de hj poderia ser complementado c um de video-aula tecnico. parabens..vlw
Boaaa, estou pensando sobre este tipo também! heheh valeu \o/
Sugestão: Clean Code. Já tem muita gente fazendo, mas esse assunto nunca perde a relevância.
Comecei a utilizar TDD, parece que o tempo necessário é maior porém nao precisar ficar resolvendo bug sempre já é algo bem satisfatório
Tema polemicooo hahsuah muito bom :D
Nao acho mt polemico nao.. Tira onda quem faz tdd. Eu vou fazendo tanta coisa uma atras da outra, que nem o card do jira ou a anotacao do confluence eu crio
Tento me policiar mas é dificil !.. Mas tenho melhorado !
Hahahah ooops
Brabo, mas se a equipe usa testes já to feliz viu...
Nice Erick, perfeito seu posicionamento. Já fiz parte de times que não tinham a cultura de code-review inclusa no dia a dia, quanto mais de testes... A cada nova feature, testavam manualmente e o resultado era bugs em produção a cada fim de sprint. Quando fui alocado no time e percebi o tamanho do problema, tentei conversar e me propus a ajudar, mas o líder era cabeçudo e não queria saber de testes usando como argumento exatamente o que você no vídeo, a pressão por entrega do time de negócios. O que você tem a dizer quando se tem pouca voz no time pra sugerir novas culturas e boas práticas? É válido chegar e escrever os testes sozinho, levando em conta que no fluxo de deploy não tem uma etapa de testes e considerando também que o time não vai manter o teste que você escrever? Você acha que é possível gradualmente ir mudando a cabeça do time e fazê-lo se adaptar a você, ou você se adapta e eles e entrega tudo sem teste?
Like 267º
Estou aprendendo JavaScript e procurei tutoriais de testes automatizados com o Jest, muito bom.
Opa! hahaha que demaais. Sim, Jest é bem bacana!
Mandou super bem Erick! Parabens!
Esse depois a gente rescreve é clássico.
olha quem está aqui!!! hahahha tmj manooo
Muito bom o conteúdo
NUNCA vi esse cenário de entrega rápido que a gente arruma depois. HAHAHAHA
Icaro Bichir HAAHAHAHA FODA
lindíssimo, falou tudo!
Em um mundo ideal é interessante ter um QA ou até mesmo uma equipe de QA's dependendo do tamanho do projeto, mas claro, isso em um mundo ideal.
discordo, qualidade é responsabilidade de dev, QA é necessário a depender da complexidade, para fazer auxiliar o time com testes mais complexos, principalmente ligados a requisitos não funcionais.
Como sempre, excelente abordagem! O que tu acha do "Consumer-Driven Contract" ? Quando conheci com mais detalhes e exemplos, percebi que é uma abordagem de testes mais próxima do usuário, onde tu gera um "contrato" dizendo que para o caso de uso onde seus inputs é X Y e Z, tem que ter F como retorno, do contrário o teste quebrou. Existem libs que facilitam essa implementação como Pact.js (github.com/pact-foundation/pact-js). Mas entendendo esse contexto, isso acaba sendo aplicável pra praticamente qualquer funcão ser testável, mesmo que derrepente fazendo "na mão". Dito isso, acho que parte do problema é esse posicionamento como desenvolvedor que tu disse (e concordo), e outra parte é de quão próximo do negócio o time esta, o quão integrado as regras o desenvolvedor esta. Do contrário, fica muito difícil ele definir cenários de testes sem conhecer muito o produto.
E por último, essa ideia de querer começar testes em tudo, sempre na minha opinião assusta os desenvolvedores. Tem que começar injetar endorfina aos poucos, pro seu organismo se viciar naquilo, e quando tu ver, já esta aplicando testes em tudo. É um processo....
Cara, tem TDD em aplicações Node.js conteinerizadas pelo Docker?
Não entendi a pergunta Victor. Docker é o ambiente que você executa sua aplicação, TDD é como você cria funções de automação para validar seu código. Acho que Docker e TDD não tenham relação
@@ErickWendelTraining Viajei, desculpe.
Show!!!
"Faz funcionar, depois a gente faz direito."
Isso NUNCA acontece, e não é só em programação não! Quando eu era network manager era a mesma coisa: "sobe esse switch de qualquer jeito só pra subir a rede, depois a gente configura direito."
"Importante é construir essa rede e colocar cliente na base, depois a gente faz documentação."
TDD é vida. Poupa muitas dores de cabeça.
Meu... que dor de cabeça!
demais! haha
Eu dei altas risadas aqui, porque é quase sempre assim: faz e bota em produção. Depois tá todo mundo tomando no c* tendo retrabalho e fazendo hora extra.
Eu estou na ponta do QA e não viam muito valor.
Daí um dia resolveram envolver o time de QA em um projeto novo.
Em pouco alguns minutos quebramos o sistema.
Depois de um tempo ouvimos a seguinte pergunta: por que não envolvemos o time de QA antes?
Comecei a realizar testes hoje. Me desejem sorte kkk
eu faço manutenção no seu código HAUHAUAHUA
Hahahaha não sei se isso é bom, ou ruim 😂😂😂😂
Estamos até hoje nessa luta hahahah
Então a empresa chega com 1 prazo fora da realidade, trabalhamos 30 dias sem parar 12h por dia ou até mais, e se não tem teste a culpa é do dev? kkkkkk bulshitagem pura desculpa
kkk conteudo top
Chama Diego rocketseat
Não entendi
@@ErickWendelTraining você falou que vai vim galera massa no canal do Netflix etc aí recomendei pra chamar Diego para trocar uma ideia