Nas empresas que trabalhei, todos os apps funcionavam muito bem, dificilmente havia bugs, e quando havia era algo bem pontual e fácil de resolver. Todas elas tinham uma característica bem em comum, a mudança constante de regras de negócio, redesign, e melhorias nos fluxos. Consequentemente, adaptar todos os testes para cada alteração dessa era extremamente ineficaz. O que eu posso dizer é que, eu prefiro um código melhor escrito com side-effects controláveis e previsíveis sem testes, do que um mostro mal escrito mas cheio de testes. Ps: eu gosto da ideia de testes, mas também não sou utópico de dizer que só funciona se tiver.
Testes é um assunto complicado porque envolve N fatores. Depende se faz parte da cultura da empresa, depende do desenvolvedor saber/querer fazer ou não os testes, etc. Porém, dentre os maiores vilões dessa história, eu sempre culpo o próprio desenvolvedor por tratar os testes como um bônus, como foi dito no vídeo (Com testes fica pronto em 8h00, mas sem testes eu faço em 4h00). Claro, em aplicações muito simples não é algo que vá fazer diferença. Mas se pegarmos algo mais complexo, a história já muda por completo.
Pelo que entendi desse vídeo, os testes de unidade auxiliam no desenvolvimento, pois é uma ferramenta para ajudar o Dev a validar as regras de negócio, puramente. E, por auxiliar na validação da lógica nas regras de negócio, o Dev consegue deixar a funcionalidade como Ok mais rapidamente, pois não precisará voltar para retestar manualmente as mesmas regras de negócio, depois que concluir as telas, pois a lógica já estará Ok (até porque, deixar para testar manualmente pela interface gráfica, se a UI estiver com algum problema, atrapalhará o andamento dos testes da regra de negócio). Nesse ponto, o Dev deve se preocupar em validar o restante do app, como a navegabilidade das telas, por exemplo. É isso mesmo? Vejo também que eu entendia errado o propósito dos testes de unidade. Eu entendia também como um plus, uma camada extra para tentar agregar mais qualidade. Acredito que seja um grande equívoco comum pelo que tenho escutado de colegas. Obrigado pelo ótimo trabalho, Jacob!
1:57 existem muita empresa que não usa teste. Nunca vi necessidade de usar teste de unidade e trabalho numa fábrica de software. E já vendemos vários softwares que geram lucros
teste realmente ajuda no desenvolvimento, minha meta que próximo ano todos os trabalho vão já ser feitos com uma pilha de teste estou hoje fazendo um sistema com mais de 300 rotas de API toda vez os teste vão ficando cada vez mais cansativos para min quanto pra empresa quando pro próprio sistema, eu sei é código escrito a mais, isso custo, o mercado as vezes não quer pagar, mas de uma forma ou de outra estou pagando com mais tempo em frente ao computador testando, tiro do meu bolso no final acredito que irar me dar mais tranquilidade
18:00 cliente que não quer pagar, o que sinto é o dev em uma constante descoberta, fazendo o dev sempre superando desafios, descobrir como fazer, depois descobrir como testar, sim é falta de prática, conhecimento no framework, também como dev começou, se logo que aprendeu a programar, foi apresentado aos teste e trabalhou em projetos com testes, tem a tendência a continuar e procurar a ter sempre os 100% coverage, depois se ligar que é mais fácil programas com os requisitos, criando testes e depois atendendo ao teste
Um passo antes, na planning que na maioria das vezes é de 30 min, acaba não detalhando ao ponto do dev ter real ciencia das atividades para começar pelo teste, também por falta de treino
MAS(em caixa alta mesmo pra reforçar), no mundo real as vezes é bem diferente. Trabalho em um banco, estamos concluindo a integração do empréstimo consignado que é o terceiro produto que estava no escopo, já em produção estão FGTS e master luz, sempre o front é criado quase que todo pra adiantar e ficamos aguardando o back liberar as API’s. Sempre criamos o fluxo logado pra validação das telas e posteriormente vamos integrando com o back. Não temos escolha e funciona bem, temos alguns QA’s que não deixam passar nada e a coisa vai dando certo. Como iríamos implementar da forma correta? Não tem como rsrs
Eu não aprendi falando testes. Mas entendi seu ponto de vista. Acredito que isso na verdade é um tipo de planilha do serviço que irá prestar. Um caminho, um tipo de guia. Porque é If e else Você disse ali vários meios de como verificar um CPF. Mas é tudo modo de como entregar pro usuário. Um exemplo. Eu quero que apareça um vídeo. Ah tem diversas maneiras de como fazer exibir um vídeo. Pode ser já com o link no vídeo , do servidor, pode ser do assets, pode ser capturado, antes de mostrar ele vai ter loading ou vai ser um container vazio ou vai ser um container que tenha um tipo de animação para ficar no local antes de exibir ou se vai exibir uma imagem antes do vídeo. O cliente não precisa saber que ali vai um loading ou um tipo de tratamento específico, o cliente quer somente o resultado e ainda tem aquela. Tem gente que vai falar mal, mas vai estar usando, ou vai falar bem e nem ter usado, o que muda é apenas a necessidade de quem é realmente é o consumidor.
Teste é um documento mais fácil de explicar regras de negócio de um produto. Auxilia na entrada de novos desenvolvedores! É o melhor do "documento" que um projeto pode ter! Muito mais que arquivo markdown com descritivos, descritivo de arquitetura. Alem de claro ser uma "proteção" contra quebras de desenvolvimentos errados por um dev que domina pouco as regras de negócio do produto.
@@FlutterandoTV de 2006 até hoje não consegui trabalhar em uma empresa que as regras de negócio fossem claras e não fossem alteradas durante o desenvolvimento do projeto. Pra mim escrever testes antes do código é utopia
Nas empresas que trabalhei, todos os apps funcionavam muito bem, dificilmente havia bugs, e quando havia era algo bem pontual e fácil de resolver. Todas elas tinham uma característica bem em comum, a mudança constante de regras de negócio, redesign, e melhorias nos fluxos. Consequentemente, adaptar todos os testes para cada alteração dessa era extremamente ineficaz.
O que eu posso dizer é que, eu prefiro um código melhor escrito com side-effects controláveis e previsíveis sem testes, do que um mostro mal escrito mas cheio de testes.
Ps: eu gosto da ideia de testes, mas também não sou utópico de dizer que só funciona se tiver.
Concordo com você, sobretudo quando possuímos uma senioridade maior, esse tipo de visão fica clara
Exatamente, eu compartilho do seu ponto. Ate pq existem testes mal feitos que não validam nada, então testar por testar não faz sentido algum
Testes é um assunto complicado porque envolve N fatores. Depende se faz parte da cultura da empresa, depende do desenvolvedor saber/querer fazer ou não os testes, etc. Porém, dentre os maiores vilões dessa história, eu sempre culpo o próprio desenvolvedor por tratar os testes como um bônus, como foi dito no vídeo (Com testes fica pronto em 8h00, mas sem testes eu faço em 4h00). Claro, em aplicações muito simples não é algo que vá fazer diferença. Mas se pegarmos algo mais complexo, a história já muda por completo.
Cadê o curso de testes?
concordo plenamente, acho que a UI deve ser desenvolvida por ultimo e quando chegar lá todas features já estão prontas e testadas.
Pelo que entendi desse vídeo, os testes de unidade auxiliam no desenvolvimento, pois é uma ferramenta para ajudar o Dev a validar as regras de negócio, puramente.
E, por auxiliar na validação da lógica nas regras de negócio, o Dev consegue deixar a funcionalidade como Ok mais rapidamente, pois não precisará voltar para retestar manualmente as mesmas regras de negócio, depois que concluir as telas, pois a lógica já estará Ok (até porque, deixar para testar manualmente pela interface gráfica, se a UI estiver com algum problema, atrapalhará o andamento dos testes da regra de negócio).
Nesse ponto, o Dev deve se preocupar em validar o restante do app, como a navegabilidade das telas, por exemplo.
É isso mesmo?
Vejo também que eu entendia errado o propósito dos testes de unidade. Eu entendia também como um plus, uma camada extra para tentar agregar mais qualidade.
Acredito que seja um grande equívoco comum pelo que tenho escutado de colegas.
Obrigado pelo ótimo trabalho, Jacob!
1:57 existem muita empresa que não usa teste. Nunca vi necessidade de usar teste de unidade e trabalho numa fábrica de software. E já vendemos vários softwares que geram lucros
teste realmente ajuda no desenvolvimento, minha meta que próximo ano todos os trabalho vão já ser feitos com uma pilha de teste estou hoje fazendo um sistema com mais de 300 rotas de API toda vez os teste vão ficando cada vez mais cansativos para min quanto pra empresa quando pro próprio sistema, eu sei é código escrito a mais, isso custo, o mercado as vezes não quer pagar, mas de uma forma ou de outra estou pagando com mais tempo em frente ao computador testando, tiro do meu bolso no final acredito que irar me dar mais tranquilidade
18:00 cliente que não quer pagar, o que sinto é o dev em uma constante descoberta, fazendo o dev sempre superando desafios, descobrir como fazer, depois descobrir como testar, sim é falta de prática, conhecimento no framework, também como dev começou, se logo que aprendeu a programar, foi apresentado aos teste e trabalhou em projetos com testes, tem a tendência a continuar e procurar a ter sempre os 100% coverage, depois se ligar que é mais fácil programas com os requisitos, criando testes e depois atendendo ao teste
Um passo antes, na planning que na maioria das vezes é de 30 min, acaba não detalhando ao ponto do dev ter real ciencia das atividades para começar pelo teste, também por falta de treino
MAS(em caixa alta mesmo pra reforçar), no mundo real as vezes é bem diferente. Trabalho em um banco, estamos concluindo a integração do empréstimo consignado que é o terceiro produto que estava no escopo, já em produção estão FGTS e master luz, sempre o front é criado quase que todo pra adiantar e ficamos aguardando o back liberar as API’s. Sempre criamos o fluxo logado pra validação das telas e posteriormente vamos integrando com o back. Não temos escolha e funciona bem, temos alguns QA’s que não deixam passar nada e a coisa vai dando certo. Como iríamos implementar da forma correta? Não tem como rsrs
@@romulodiego4194 não há problema fazer a view por primeiro, desde que ela seja independente da regra de negocio no primeiro momento.
No Flutter, devemos testar páginas e fluxos, pois o domínio do frontend é o presenter, ou seja, a parte mais importante.
Comece pelo design system, não pelas entidades.
Tem algum link de conteúdo dessa abordagem?
@@F6GAMEPLAY Pesquise sobre Design tokens, esses são as "entidades" do frontend
Para mim dependerá da arquitetura, algumas arquiteturas de softwares tornam os testes unitários dificílimos de serem feitos.
Eu não aprendi falando testes.
Mas entendi seu ponto de vista. Acredito que isso na verdade é um tipo de planilha do serviço que irá prestar. Um caminho, um tipo de guia.
Porque é If e else
Você disse ali vários meios de como verificar um CPF. Mas é tudo modo de como entregar pro usuário.
Um exemplo. Eu quero que apareça um vídeo.
Ah tem diversas maneiras de como fazer exibir um vídeo. Pode ser já com o link no vídeo , do servidor, pode ser do assets, pode ser capturado, antes de mostrar ele vai ter loading ou vai ser um container vazio ou vai ser um container que tenha um tipo de animação para ficar no local antes de exibir ou se vai exibir uma imagem antes do vídeo. O cliente não precisa saber que ali vai um loading ou um tipo de tratamento específico, o cliente quer somente o resultado e ainda tem aquela. Tem gente que vai falar mal, mas vai estar usando, ou vai falar bem e nem ter usado, o que muda é apenas a necessidade de quem é realmente é o consumidor.
Teste é um documento mais fácil de explicar regras de negócio de um produto. Auxilia na entrada de novos desenvolvedores! É o melhor do "documento" que um projeto pode ter! Muito mais que arquivo markdown com descritivos, descritivo de arquitetura. Alem de claro ser uma "proteção" contra quebras de desenvolvimentos errados por um dev que domina pouco as regras de negócio do produto.
alem de claro ajudar na manutenabilidade do sistema por qqr desenvolvedor
Tem o canal do andre okazaki, ele fala muito de teste
Quem consegue criar os testes antes do código sem saber o que vai precisar mockar???
quem sabe as regras de negócio
@@FlutterandoTV de 2006 até hoje não consegui trabalhar em uma empresa que as regras de negócio fossem claras e não fossem alteradas durante o desenvolvimento do projeto. Pra mim escrever testes antes do código é utopia