Otimo video E realmente TDD é realmente isso Vc aprende como implementar para perceber que não é todo projeto e nem toda empresa que se adapta a ele Faz parte da vida
Na época que comecei, teste unitário era muito subestimado e agora é muito superestimado. Teste unitário é útil sim, mas o valor maior dele só é percebido depois que o sistema passa por evoluções, para alertar que a evolução que o desenvolvedor realiza no sistema poderá trazer bugs de impacto. O problema é que muito desenvolvedor tem o viés de que teste unitário testa tudo e esquece de ver a situação em que o projeto se encontra. O mais valioso é testar as integrações e automatizá-las. Eu sempre tenho a metáfora de um carro na mente: Ele tem roda, câmbio, motor, diferencial, embreagem, caixa de direção, eixo, escapamento e todos eles precisam ter os padrões e medidas corretas, sendo necessário uma verificação de todas essas peças. Porém, eu só consigo dizer para um cliente comprar esse carro quando todas elas se juntam, fazem o carro andar e esse processo se repete várias vezes. Não dá pra vender carro com uma foto do desmonte de um que passou pelo Longa Duração da Quatro Rodas. Quanto a cobertura de testes, passando dos 70-80% o tempo para implementar novos testes aumenta exponencialmente e testa casos muito específicos. E quanto a Flaky Tests, provavelmente alguma etapa de limpeza do teste anterior foi esquecida, ou alguma coisa está faltando no setup.
Boa noite, Pedro. Primeiramente, muito bom seu vídeo! Concordo que as métricas de coverage de testes são usadas de maneira equivocada e que os testes de unidade devem testar somente comportamento. Porém, em relação ao TDD, muito é dito sobre essa prática, mas acredito que o entendimento sobre ela ainda é difundido de maneira equivocada. TDD é sobre desenvolver software e não meramente sobre testá-lo. Te convido a ler a obra e conhecer os detalhes e como utilizá-lo corretamente (o livro em si é bem divertido). TDD é sim muito útil para desenhar APIs de componentes que ainda não temos e comportamento que não conhecemos! Com relação ao último ponto, realmente não temos como testar um software que não sabemos o que ele tem de fazer, e até aí nem deveria ser possível codificá-lo kkkk. Abraços e parabéns pelo trabalho!
Ótimo vídeo! Eu só discordo do ponto do TDD... eu acho que é o oposto. Especialmente quando você tem apenas ideias vagas da implementação que o TDD pode ser útil, pois você começa pensando no output e no design do que está implementando; talvez seja porque eu me habituei com ele nestes casos. Sem problema a resolver não tem código pra escrever, e se você já tem o problema, pode descrever ele com um teste que falha e aí implementar a solução... Refatorar um código complexo, que foi crescendo sem teste algum geralmente inviabiliza a implementação. Ninguém quer "mexer no que já está funcionando". Nas diversas vezes que "pulei" o TDD nunca mais consegui refatorar para por testes no lugar 😅. Eu acredito inclusive que estes sejam os caminhos que levam aos Mocks, que eu também acredito não serem muito bons e acabam criando aqueles testes que não testam a realidade, como você comentou.
8:38 Concordo plenamente que testes não é um canivete suíço. Mas a falta de requisito ou delimitação do sistema/escopo não é um erro de etapas anteriores??? Até porque eu posso criar um teste que falha mesmo faltando uma API ou lógica da resolução do problema, porém eu já sei o que preciso obter de input e entregar de output (dado escopo e requisitos). E os testes de cobertura, dependem da criticidade da regra de negócio que ele atente. Ex: um código que gera um card para ser mostrado na tela do usuário e uma validação de chave de criptografia, o primeiro se falhar, o máximo que vai acontecer é um card em branco ou todo bugado, já o segundo pode dar até processo. Mas faltou citar que a cobertura de teste está ligado ao quão abrangentes eles são... pois você pode ter mil testes testando um único if ou 100 testes cobrindo toda a classe/modulo/função (quantidade ≠ qualidade).
No meu caso em particular eu tenho lidado só com o desenvolvimento de SDKs e APIs, como normalmente ideias como API First e Contract First são fundamentais nesse meio, não dá pra fugir de coisas como stubs e mocks, além de usarmos práticas que estão no TDD. Aqui na empresa onde eu trabalho é exigido 100% de cobertura sem choro e nem vela, mas acho que o maior motivador é trabalharmos com monorepo.
Fala Pedro, parabéns pelo video! Sempre falei isso que você retrata no video e agora tenho um link do youtube para mandar para o pessoal do trampo entender o que eu sempre tentei falar. 😄
Nossa esse vídeo é muito necessário!!! kkkk Aqui na empresa fazemos testes unitários de aplicações que já estão em PRD, e o porquê disso é : "Não tem um porquê, testes são importantes " kkkkk A gente perde tempo valioso que poderia estar investindo em outras coisas escrevendo testes de implementações que já estão rodando sem bugs , não faz sentido essa idolatria louca
ótimo conteúdo Pedro! parabens por sempre ser direto ao ponto. Só uma correção que faria sobre o DDD, ao menos do meu ponto de vista. Tentar criar os testes quando vc tem pouca informação pode ser bem útil para vc entender o problema. Seria como um escritor que esta criando rascunhos para sua mente fluir com novas ideias. Me diz ai se isso faz sentido pra ti.
Eu acho que vai depender do caso e do que é o teu entregável. Conversando com um amigo ele me explicou que na empresa dele existem testes que garantem alguns comportamentos não desejados inicialmente mas que já foram pra produção e estão sendo largamente utilizados mas isso deve ser 1% das companhias.
Só verdades! Uso TDD pra fazer coisas que tenho especificação. Pra protótipo ou MVP as vezes escrevo e depois faço os testes e mesmo assim pego bugs. Usar TDD como religião pode levar a mais estresse e frustração do que efetivamente progresso no desenvolvimento. Vejo que sempre é necessário ter testes automatizados mas nem sempre atrelados à uma perspectiva de TDD rigorosamente.
Eu só escrevo teste para casos especiais. No +, só alguns, para "dar tração" qdo ainda não detectei 1 caso crítico ou o código da f() ainda está muito imaturo.
Opa, entendo que o que tu comentou sobre mock ta certo, mas eu te pergunto: porque não ter um mock em que dado que o objeto veio como deveria ter vindo, com os campos que ele deveria ter segundo o "modelo" mockado, a minha classe funciona? isso ajuda a entender se o erro está na integraçao ou na comunicaçao de serviços, ao inves de ficar igual barata tonta tendo que duvidar se o código do projeto está ok, quando o problema é na comunicaçao. faz sentido oq eu to pensando?
Eu discordo em relação aos mocks, pois eu gostaria de testar um certo trecho de código, em uma situação X, Y ou Z. Por exemplo, tratamento de erros. Você citou, "E se for uma situação que o seu mock não esperava?", então o tratamento de erros do software precisa ser refatorado. E se um QA descobrir que o software quebrou quando o a outra funcionalidade (que era mockada nos testes), recebeu uma resposta que não era esperada? Os testes unitários com mock iriam ajudar a identificar aonde falhou.
O problema da mock não é a flexibilidade de gerar dados e situações, ainda mais com geradores de fake data, mas o tato do desenvolvedor em saber quais são essas situações. Mocks são úteis para testar, mas não são tudo. Ainda vai ter aquele dado em situação real que vai te causar pedra no sapato e você não sabe dizer pelo dado o que aconteceu, e se tiver esses dados em mãos é melhor do que mockar uma situação que ocorre com eles.
@@tenazattomock te ajuda pra isso! Quando identificado que um dado/comportamento gera um bug, vc mocka esse dado/compartamento para ve o teste quebrando!
Não ficou claro pra mim testar a funcionalidade ao invés da unidade. Isso não quebraria a pirâmide de teste? Teste funcional seria um end to end teste? Esses testes são importantes mas as vezes é mais difícil de encontrar um erro específico quando multiplas equipes trabalham no mesmo código. Muito bom o vídeo... Like dado por mais conteúdos como esse 🎉
Teste unitário (testar todas as funções, cobertura, etc.) é um pé no saco absurdamente grande. Isso já é um motivo mais do que suficiente para não escrevê-los. Hoje eu automatizo testes de integração e funcionalidade. Acho importante (no passado eu não fazia nem isso). Vou tentar uma outra metáfora aqui => Assembly é mais rápido e mais eficiente do que qualquer outra linguagem. Então por que não programamos em Assembly? Porque é um pé no saco!
Cara EU TE AMO! Eu sempre intuí que testes unitários são um exagero. Testes de integração, apesar de mais lentos e complexos, asseguram se efetivamente a aplicação quebrou ou não com as mudanças.
Eu acho engraçado o ranço que muita gente tem contra testes, sabe? Parece coisa de quem tentou testar algo e não conseguiu ou não fazia ideia do que testar. Passei o último mês mergulhado em testes para apresentar um workshop. Depois desse tempo, percebi que mesmo não tendo cenários desenhados pelos processos anteriores, consegui trazer para o meu desenvolvimento uma confiança e agilidade muito satisfatórias. Sinto que meu desenvolvimento se tornou mais sólido e confiável. Hoje posso bater o pé e dizer : sim sim e não não. Notei tbm que com o passar o tempo e com o conhecimento que foi chegando, fui descobrindo o que deveria ser testado, os tipos de testes e elaborando cada cenário possível dentro do contexto que gostaria de validar. Não saber o que é uma unidade e o que a define é um problema. Não saber o que testar é um problema. Não saber dos limites do que deve ser testado é um problema. Não se atentar para que um teste de unidade não se torne um de integração é um problema. Não saber é o que e como testar é um problema. A verdade é que testes são excelentes! Não dominar o tema que é um problema e dizer que é 'encheção de linguiça' é uma balela de gente que não domina o que faz. Sinto muito aos que se ofenderão com essa informação.
Parabéns pelo vídeo! mas se você não sabe o que irá testar então não tem sentido escrever seu código, TDD é valido para criação de componentes, uma vez que se começa com TDD é onde há o brilho, não existe TDD sobre código já existente sem que haja sofrência, o fato é que a culpa de uma necessidade de um código adaptável é do DESIGN e não do TESTE, TDD é só uma metodologia, se tiver problemas com teste, terá mesmo sem TDD, só esse ponto de discordo de você, de resto é isso aí, faltou talvez dizer que há ferramentas para melhorar a qualidade do teste como testes de mutação!
Cara, eu adoro a maneira como você explica e basicamente, conversa com a gente! Continua mano!
Putz... amém!🙌🏼🙌🏼🙌🏼🙌🏼Alguém falando finalmente q teste unitario deve ser para funções puras!!!😂 Obrigado enormemente por isso Pedro!!!
Seus videos são muito bons, continua mano, so vai, seu canal vai bombar cada vez mais!
Otimo video
E realmente TDD é realmente isso
Vc aprende como implementar para perceber que não é todo projeto e nem toda empresa que se adapta a ele
Faz parte da vida
Na época que comecei, teste unitário era muito subestimado e agora é muito superestimado. Teste unitário é útil sim, mas o valor maior dele só é percebido depois que o sistema passa por evoluções, para alertar que a evolução que o desenvolvedor realiza no sistema poderá trazer bugs de impacto. O problema é que muito desenvolvedor tem o viés de que teste unitário testa tudo e esquece de ver a situação em que o projeto se encontra.
O mais valioso é testar as integrações e automatizá-las. Eu sempre tenho a metáfora de um carro na mente: Ele tem roda, câmbio, motor, diferencial, embreagem, caixa de direção, eixo, escapamento e todos eles precisam ter os padrões e medidas corretas, sendo necessário uma verificação de todas essas peças. Porém, eu só consigo dizer para um cliente comprar esse carro quando todas elas se juntam, fazem o carro andar e esse processo se repete várias vezes. Não dá pra vender carro com uma foto do desmonte de um que passou pelo Longa Duração da Quatro Rodas.
Quanto a cobertura de testes, passando dos 70-80% o tempo para implementar novos testes aumenta exponencialmente e testa casos muito específicos. E quanto a Flaky Tests, provavelmente alguma etapa de limpeza do teste anterior foi esquecida, ou alguma coisa está faltando no setup.
Caraca que metáfora boa mano
Boa noite, Pedro.
Primeiramente, muito bom seu vídeo!
Concordo que as métricas de coverage de testes são usadas de maneira equivocada e que os testes de unidade devem testar somente comportamento. Porém, em relação ao TDD, muito é dito sobre essa prática, mas acredito que o entendimento sobre ela ainda é difundido de maneira equivocada. TDD é sobre desenvolver software e não meramente sobre testá-lo. Te convido a ler a obra e conhecer os detalhes e como utilizá-lo corretamente (o livro em si é bem divertido). TDD é sim muito útil para desenhar APIs de componentes que ainda não temos e comportamento que não conhecemos! Com relação ao último ponto, realmente não temos como testar um software que não sabemos o que ele tem de fazer, e até aí nem deveria ser possível codificá-lo kkkk.
Abraços e parabéns pelo trabalho!
Ótimo vídeo!
Eu só discordo do ponto do TDD... eu acho que é o oposto. Especialmente quando você tem apenas ideias vagas da implementação que o TDD pode ser útil, pois você começa pensando no output e no design do que está implementando; talvez seja porque eu me habituei com ele nestes casos. Sem problema a resolver não tem código pra escrever, e se você já tem o problema, pode descrever ele com um teste que falha e aí implementar a solução... Refatorar um código complexo, que foi crescendo sem teste algum geralmente inviabiliza a implementação. Ninguém quer "mexer no que já está funcionando". Nas diversas vezes que "pulei" o TDD nunca mais consegui refatorar para por testes no lugar 😅. Eu acredito inclusive que estes sejam os caminhos que levam aos Mocks, que eu também acredito não serem muito bons e acabam criando aqueles testes que não testam a realidade, como você comentou.
otima visão sobre como lidar/escrever testes!
8:38 Concordo plenamente que testes não é um canivete suíço. Mas a falta de requisito ou delimitação do sistema/escopo não é um erro de etapas anteriores???
Até porque eu posso criar um teste que falha mesmo faltando uma API ou lógica da resolução do problema, porém eu já sei o que preciso obter de input e entregar de output (dado escopo e requisitos). E os testes de cobertura, dependem da criticidade da regra de negócio que ele atente. Ex: um código que gera um card para ser mostrado na tela do usuário e uma validação de chave de criptografia, o primeiro se falhar, o máximo que vai acontecer é um card em branco ou todo bugado, já o segundo pode dar até processo. Mas faltou citar que a cobertura de teste está ligado ao quão abrangentes eles são... pois você pode ter mil testes testando um único if ou 100 testes cobrindo toda a classe/modulo/função (quantidade ≠ qualidade).
Seguindo essa linha, poderia falar sobre tratamento de exceção em algum vídeo?
No meu caso em particular eu tenho lidado só com o desenvolvimento de SDKs e APIs, como normalmente ideias como API First e Contract First são fundamentais nesse meio, não dá pra fugir de coisas como stubs e mocks, além de usarmos práticas que estão no TDD.
Aqui na empresa onde eu trabalho é exigido 100% de cobertura sem choro e nem vela, mas acho que o maior motivador é trabalharmos com monorepo.
Fala Pedro, parabéns pelo video! Sempre falei isso que você retrata no video e agora tenho um link do youtube para mandar para o pessoal do trampo entender o que eu sempre tentei falar. 😄
Video muito bom! sucesso Pedro.
Testes que eu julgo importantes pra mim é de garantir integridade das features que foram implementadas
Muito bom cara, parabéns pelo conteúdo!
Nossa esse vídeo é muito necessário!!! kkkk Aqui na empresa fazemos testes unitários de aplicações que já estão em PRD, e o porquê disso é : "Não tem um porquê, testes são importantes "
kkkkk
A gente perde tempo valioso que poderia estar investindo em outras coisas escrevendo testes de implementações que já estão rodando sem bugs , não faz sentido essa idolatria louca
ótimo conteúdo Pedro! parabens por sempre ser direto ao ponto. Só uma correção que faria sobre o DDD, ao menos do meu ponto de vista. Tentar criar os testes quando vc tem pouca informação pode ser bem útil para vc entender o problema. Seria como um escritor que esta criando rascunhos para sua mente fluir com novas ideias. Me diz ai se isso faz sentido pra ti.
Excelente video!
Esse canal é muito bom!
Eu acho que vai depender do caso e do que é o teu entregável. Conversando com um amigo ele me explicou que na empresa dele existem testes que garantem alguns comportamentos não desejados inicialmente mas que já foram pra produção e estão sendo largamente utilizados mas isso deve ser 1% das companhias.
Só verdades! Uso TDD pra fazer coisas que tenho especificação. Pra protótipo ou MVP as vezes escrevo e depois faço os testes e mesmo assim pego bugs. Usar TDD como religião pode levar a mais estresse e frustração do que efetivamente progresso no desenvolvimento.
Vejo que sempre é necessário ter testes automatizados mas nem sempre atrelados à uma perspectiva de TDD rigorosamente.
Eu só escrevo teste para casos especiais. No +, só alguns, para "dar tração" qdo ainda não detectei 1 caso crítico ou o código da f() ainda está muito imaturo.
Opa, entendo que o que tu comentou sobre mock ta certo, mas eu te pergunto: porque não ter um mock em que dado que o objeto veio como deveria ter vindo, com os campos que ele deveria ter segundo o "modelo" mockado, a minha classe funciona? isso ajuda a entender se o erro está na integraçao ou na comunicaçao de serviços, ao inves de ficar igual barata tonta tendo que duvidar se o código do projeto está ok, quando o problema é na comunicaçao. faz sentido oq eu to pensando?
oxe, por isso que existem varios tipos de testes, cada tipo de teste é para um cenario especifico sendo que cada um tem um custo diferente tb
puta sabedoria desbalanceada bixo
Não gosto de Go mas já cheguei dando uma voadora no like, toma tibiano!
Excelente vídeo!!!
Meu problema nem é com o TDD em si, mas com a seita que se criou em volta dele, eita povo doido kkk
😂 basta botar na mão do usuário que acha erro... Achei um bug no yt como notificar?
Eu discordo em relação aos mocks, pois eu gostaria de testar um certo trecho de código, em uma situação X, Y ou Z. Por exemplo, tratamento de erros. Você citou, "E se for uma situação que o seu mock não esperava?", então o tratamento de erros do software precisa ser refatorado. E se um QA descobrir que o software quebrou quando o a outra funcionalidade (que era mockada nos testes), recebeu uma resposta que não era esperada? Os testes unitários com mock iriam ajudar a identificar aonde falhou.
O problema da mock não é a flexibilidade de gerar dados e situações, ainda mais com geradores de fake data, mas o tato do desenvolvedor em saber quais são essas situações. Mocks são úteis para testar, mas não são tudo.
Ainda vai ter aquele dado em situação real que vai te causar pedra no sapato e você não sabe dizer pelo dado o que aconteceu, e se tiver esses dados em mãos é melhor do que mockar uma situação que ocorre com eles.
@@tenazattomock te ajuda pra isso! Quando identificado que um dado/comportamento gera um bug, vc mocka esse dado/compartamento para ve o teste quebrando!
Não ficou claro pra mim testar a funcionalidade ao invés da unidade. Isso não quebraria a pirâmide de teste? Teste funcional seria um end to end teste? Esses testes são importantes mas as vezes é mais difícil de encontrar um erro específico quando multiplas equipes trabalham no mesmo código. Muito bom o vídeo... Like dado por mais conteúdos como esse 🎉
Pedrão, por favor! Faça o desafio #1brc
Teste unitário (testar todas as funções, cobertura, etc.) é um pé no saco absurdamente grande. Isso já é um motivo mais do que suficiente para não escrevê-los. Hoje eu automatizo testes de integração e funcionalidade. Acho importante (no passado eu não fazia nem isso). Vou tentar uma outra metáfora aqui => Assembly é mais rápido e mais eficiente do que qualquer outra linguagem. Então por que não programamos em Assembly? Porque é um pé no saco!
Ah nao, acabei de aprender a fazer TDD no curso do Filipe Deschamps kkkkkkk
Pelo menos agora vai usar TDD com moderação
Otímo video
Seus videos são ótimos, voce da uma zoada no JavaScript
Cara EU TE AMO! Eu sempre intuí que testes unitários são um exagero. Testes de integração, apesar de mais lentos e complexos, asseguram se efetivamente a aplicação quebrou ou não com as mudanças.
Eu escrevo teste para ajudar a refatorar o código :b
Eu nunca escrevi testes, tenho preguiça até nisso kkkk joga pro usuário testar e ferro 😅
Eu acho engraçado o ranço que muita gente tem contra testes, sabe? Parece coisa de quem tentou testar algo e não conseguiu ou não fazia ideia do que testar.
Passei o último mês mergulhado em testes para apresentar um workshop. Depois desse tempo, percebi que mesmo não tendo cenários desenhados pelos processos anteriores, consegui trazer para o meu desenvolvimento uma confiança e agilidade muito satisfatórias. Sinto que meu desenvolvimento se tornou mais sólido e confiável. Hoje posso bater o pé e dizer : sim sim e não não. Notei tbm que com o passar o tempo e com o conhecimento que foi chegando, fui descobrindo o que deveria ser testado, os tipos de testes e elaborando cada cenário possível dentro do contexto que gostaria de validar.
Não saber o que é uma unidade e o que a define é um problema.
Não saber o que testar é um problema.
Não saber dos limites do que deve ser testado é um problema.
Não se atentar para que um teste de unidade não se torne um de integração é um problema.
Não saber é o que e como testar é um problema.
A verdade é que testes são excelentes!
Não dominar o tema que é um problema e dizer que é 'encheção de linguiça' é uma balela de gente que não domina o que faz. Sinto muito aos que se ofenderão com essa informação.
to justamente travado nisso :/
só fala mal do TDD quem não sabe fazer direito
Parabéns pelo vídeo! mas se você não sabe o que irá testar então não tem sentido escrever seu código, TDD é valido para criação de componentes, uma vez que se começa com TDD é onde há o brilho, não existe TDD sobre código já existente sem que haja sofrência, o fato é que a culpa de uma necessidade de um código adaptável é do DESIGN e não do TESTE, TDD é só uma metodologia, se tiver problemas com teste, terá mesmo sem TDD, só esse ponto de discordo de você, de resto é isso aí, faltou talvez dizer que há ferramentas para melhorar a qualidade do teste como testes de mutação!
nunca nem comecei. rs
"use case" fica melhor em pt-br "caso de uso". Pq "uso de caso" não faz muito sentido ksks
Eu acho um saco esses teste, as empresas querem pra ontem, como desenvolver clean code e testar
Pense num click bait